Need help for bugfix

May 24, 2016

I already reported this bug to the team. But the consequences seem to be more serious than I thought. I despairing of finding a work around. 

I insert many webobjects. Now I updates the webobject html file. If I right click "web objects" > "edit" > "check link" it shows me the correct new file. If I click "web objects" > "open" it shows me "C:/Users/MyProfil/AppData/Local/Temp/Articulate/Storyline/6XAiNwhb3kz/zip/66YLocGL1zx/index.html" which is the old file. If I delete this temporary file and republish the whole project it recreates the old file. 

If I am reselecting the web objects folder I have the same effect. How can I storyline force to update the webobject index.html file?

Where can I find the storage for the old webobject html file to delete it?

13 Replies
Christie Pollick

Hi, Alexandra -- Thanks for reaching out! As you mentioned that you have already 'reported this bug to the team', may I ask if that means that you previously submitted a ticket to our Support Engineers? If so, do you have a case number you are able to share? I did a search with your name and was unable to locate a ticket to read up on their notes. 

Alexandra Masche

Here is my post, which I also send in as a feature request: https://community.articulate.com/discussions/articulate-storyline/relative-paths-for-web-objects#reply-355464  (Request Number: 00793313; ref:_00D30Txo._50033wuEZx:ref)

Hope this was right or is there a different bugtracker system which I don't know?

 

 

Alexandra Masche

After a longer conversation with the support team (many thanks!), here is an update for all who struggle with this issue:

There is no way to update local webobjects. Once there are included, storyline keeps the first version of the weboject. 

If you have to update a webobject there are only two workarounds to do so:

1.    Delete the webobject in the storyline document each time you update the weboject and insert it again after you saved the project. 

2.    Rename the webobject folder each time you update them. Then go to the storyline document update the link / relink the renamed webobject folder and saved the project.

Both solutions may involve a lot work. I wrote a little batch file which automatically rename all my almost 100 webobject folder. Anyways, in the second steps I have to go through all slides and relink them manually.

Additional information:

When you use “Web Object” > “Edit” and then “test link

You will see your updated webobject files, which is recognized by storyline under this link. But storyline still keeps the old version of the webobjects (it was copied to the project file and won’t be updated).  

To see the real status of your projects you have to use this way:

Web Object” > “Open

This option previews the file that is already inserted as a web object in your project file (and won’t be updated; except solutions above).

I requested a fix / feature request for this topic. So let’s cross the fingers that articulate will get active here. 

Alexandra Masche

Hi Lesli,

could you my have a look what the status of this issue is ( https://community.articulate.com/discussions/articulate-storyline/relative-paths-for-web-objects#reply-355464 (Request Number: 00793313; ref:_00D30Txo._50033wuEZx:ref  and  Feature Request Number: 00811048; ref:_00D30Txo._50033xBPFT:ref).

This issue bothers me a lot, because each change involves a lot of work. So If I would know that the developer work on a fix for this bug, I would postpone all activities which are related to webobjects. Having more informations would make my planning much easier.

Thank you!

 

Christie Pollick

Hi, Alexandra -- Thanks for reaching out to touch base and although we do not have the functionality that you have requested available at this time, the following message was sent recently via email in response to your feature requests:

"Thanks for suggesting a feature! We love to hear what our customers have to say, and we pay close attention to your suggestions.  As we plan new features, we take your requests into consideration. To give you some insight into our process, here's how we evaluate each request: 

1) First, we see if the request is currently possible, and we let you know if there's a way to achieve your goal. 

2) If the request isn't currently supported, we estimate the value it could bring to our products. 

3) If a request adds value, we submit it to our product development team for review. 

4) Our development team gauges the impact of the request. Will it benefit many of our customers, or does it meet a niche need? 

5) If the request is approved, we add it to the development pipeline where it gets designed, developed, and tested. 

6) When the feature is ready, we release it and announce its arrival. 

We can't promise that a feature request will be fulfilled, but we work hard to address the issues that impact our customers the most. We’ll be in touch if we have questions about your request. And thanks again for helping us improve our products!"

Alexandra Masche

Hi Christie,

thank you for your quick response! I got this email and recognized it. It would be very helpful to get a feedback after the bug is evaluated (step 5).

If development team comes to the decision that they don't fix a bug / implement a feature I will never hear about it. It would make a huge different to know if the development team is working on it or not.

At the moment I have to take a decision just guessing if the development team thinks it is worth to pay attention to it or not. At the moment this means I have to postpone a task and wait, to abdicate a feature I would like to realize or to use a workaround, which often involves a lot of effort.

I love to contribute to storyline whenever I reporting bugs. I would really appreciate to get a feedback in return, which make my developing process a bit more  predictable.

 

Ashley Terwilliger-Pollard

Hi Alexandra,

 I wanted to clarify that it's not considered a bug or a defect in the software but a feature request as it's not something we support currently per this documentation. 

For feature requests or bugs that we report to our QA team, we're unable to share information in regards to a timeline for a fix/new release or information regarding if it'll be included in a future release or update, and that's why you don't hear back after step 5 (or earlier in the process) in regards to the status of feature requests. 

As for bugs and features and determining that we'll never include them - that's something our team doesn't do. They may decide it's not in the next update, but if we continue to hear user feedback and requests for something that may change the status or timeline. 

Alexandra Masche

Hi Ashley, 

I am aware that articulate does not considered this issue as a bug. From my user perspective this issue behaves like a bug. Because I know no program, there I kan select and relink a file and this action has no effect (Why an relinking option if the old file always keeps in place?). Furthermore it looks quite awkward to me, that there is no way to change an included file, except deleting it.

I don't want to bother you, complaining a lot. I am sorry for that! I just wanted to let you know, that I would appreciate an earlier feedback about what articulate means to do next - for both feature request and bugs. This would make my developing process more predictable.

This is why ask to get some information about this issue.  

This discussion is closed. You can start a new discussion or contact Articulate Support.