Has anyone experienced master slides randomly changing since the latest update?
I opened the file, check for something but did not make any changes. I closed the file (I do not recall if I saved or not) and come to find out there are several slides where the master slide background was randomly changed.
Just contributing that myself and my colleagues also have this problem. When working on a project we have all noticed that the slide layout will change on certain/random slides spontaneously. It's a little frustrating. In our organisation, we can only share to network drives however I can't understand how this makes any impact. Articulate is only opening a saved file from the network location, we run the application itself locally. The spontaneous changes to certain slides (layout changing despite any action being given to do so) very much seems to be a bug within the software itself. This has occurred across all projects I've ever worked on, albeit, it's only been 4 projects in total and has continued to occur across all updates that Articulate has received during the 8 months I've had the application.
The Storyline file is not a saved file; it is a series of zipped, saved files. Any sort of network hiccough, buffering pause, or stray quark flying through your network during the compression phase can cause enough of a problem to introduce corruption. That's why local saving, then uploading after the zipping is done is safer. To be fair, MS uses the same scheme for office files, and they seem to be much more robust.
I would suggest that it might help you to go through the project, and reduce it to only one master. It is very easy to end up with tons of Masters, and I don't think that load aids good program function.
Hey Walt, please excuse my ignorance if I've not interpreted your response correctly. When you say that a storyline file is not a saved file, but rather is a series of zipped, saved files, are you referring to a module that has been exported ready to publish? I am referring to opening a singular .story file. Just to ensure we're both on the same page, I can save a project as a .story file and create and export of files via publish and the eLearn course behaves as expected. As an example, I might re-open the .story file a week later, and it opens as expected in the previous saved state. Let's say, for example, that the project contains 30 slides. I might go in and make a small edit to a line of text on slide 28. Before I re-save the the .story file to reflect the changes I've made, or, re-publish to export the course files, I notice that despite not having made any changes to slide 5, the layout has automatically changed. I have started to become more observant with this lately, but it seems to be that making an edit on one slide can cause the layout on a random slide also contained within the course to also change. On the last project, this was the exact nature of the problem I observed. I re-opened a saved .story file, checked the layout was ok, made a small change, re-checked the layout and observed a random slide had changed. Easy to work through with small modules, but a little more frustrating when working on a larger eLearn to have to go back and check the slide layout for all slides when only making edits to one page prior to re-saving to ensure the bug hasn't cropped up again.
I am referring to what you see on the network as the .story file. It is not, as you say, a singular .story file, it is a zipped file. I just changed the extension of one from .story to .zip and unzipped it. It is a rather small (1,200 kb, 1 slide, 2 pictures) file, and when extracted contains 16 folders, and 65 files. I say this to say that any sort of network hiccough, buffering pause, or stray quark flying through your network during the compression/decompression phase can cause enough of a problem to introduce corruption. That's why local saving, then uploading after the zipping (of the .story file as a .story file) is recommended. Please note that I am not saying the network is for certain the problem, only that it could be. It is possible that changing one slide is not what changes another slide. It might be that the second slide (because of something in the zipping and unzipping and traveling back and forth to the network) is slightly fuzzy, and opening it causes the changes. I'm saying it could happen, and you can't know for sure until you copy the saved file up and down, from local to network, rather than saving and opening directly to the network, and maybe not even then.
Of course, there is no guarantee that I'm on the right track, and there could be other causes that I know nothing about. But I think that's where I would look first. Also, I'd reinstall.
This is still happening, it has happened on my most recent project and I forgot all about the issue and used slide masters without realising the problems it could cause later on.
Now every time I load up my storyline file and start to make amends there will be a few slides that shift their slide master from one to another. As part of my routine I have to check each slide master on every slide before I publish, but the only way to stop this is to not use slide masters at all.
It also happens with projects I take over from other developers.
My IT policy backs up all local files on my hard drive to Microsoft OneDrive, a shared, synchronized drive. I am also experiencing this issue, but I fail to find a way to save locally without engaging the OneDrive upload cycle, as my USB ports and any external drives are locked out.
I can appreciate how perhaps saving the program on a network drive could cause the overall .storyline file to become corrupt. To be fair, even this seems like a bit of a stretch. But when considering Articulate Storyline and the 100s of features and elements that can be contained within a project, why is it consistently the slide master changing random slides when saving? Theoretically, the font size, type, layout are all very interchangeable, the sequence of slides in a project etc. It is only ever the slide master updating and changing random slides in a project that is the problem and I am convinced it's a bug rather than choosing to save to a network drive.
This may not be a solution, but I did find that one slide spontaneously changed to a different Master while I was working on the .story file. I tried to apply the previous layout, but it was no longer available as a selection. Only the default masters were selectable. So I closed the file and waited. After my OneDrive completed the upload that was auto-saved, thus synchronizing the file on my hard drive with the OneDrive, I reopened the file, and the slide was restored to the original Master layout. This suggests to me that it is futile to change slide layouts when this happens. Something else is going on. Perhaps file saving permissions are being violated during the automatic upload process.
I now get around this issue by saving my .Story file as one of two alternate names. If Version A is still being uploaded and file permissions are blocked on some slides, I Save As Version B. When the path is clear, I save B and Save As A again. That's my solution for now.
10 Replies
Sorry you're experiencing these issues, Susan!
Let's start with these tactics to get things running smoothly again:
If you still see random changes, connect with us in a support case so we can take a closer look. We'll reach out soon after testing!
Just contributing that myself and my colleagues also have this problem. When working on a project we have all noticed that the slide layout will change on certain/random slides spontaneously. It's a little frustrating. In our organisation, we can only share to network drives however I can't understand how this makes any impact. Articulate is only opening a saved file from the network location, we run the application itself locally. The spontaneous changes to certain slides (layout changing despite any action being given to do so) very much seems to be a bug within the software itself. This has occurred across all projects I've ever worked on, albeit, it's only been 4 projects in total and has continued to occur across all updates that Articulate has received during the 8 months I've had the application.
The Storyline file is not a saved file; it is a series of zipped, saved files. Any sort of network hiccough, buffering pause, or stray quark flying through your network during the compression phase can cause enough of a problem to introduce corruption. That's why local saving, then uploading after the zipping is done is safer. To be fair, MS uses the same scheme for office files, and they seem to be much more robust.
I would suggest that it might help you to go through the project, and reduce it to only one master. It is very easy to end up with tons of Masters, and I don't think that load aids good program function.
Hey Walt, please excuse my ignorance if I've not interpreted your response correctly. When you say that a storyline file is not a saved file, but rather is a series of zipped, saved files, are you referring to a module that has been exported ready to publish? I am referring to opening a singular .story file. Just to ensure we're both on the same page, I can save a project as a .story file and create and export of files via publish and the eLearn course behaves as expected. As an example, I might re-open the .story file a week later, and it opens as expected in the previous saved state. Let's say, for example, that the project contains 30 slides. I might go in and make a small edit to a line of text on slide 28. Before I re-save the the .story file to reflect the changes I've made, or, re-publish to export the course files, I notice that despite not having made any changes to slide 5, the layout has automatically changed. I have started to become more observant with this lately, but it seems to be that making an edit on one slide can cause the layout on a random slide also contained within the course to also change. On the last project, this was the exact nature of the problem I observed. I re-opened a saved .story file, checked the layout was ok, made a small change, re-checked the layout and observed a random slide had changed. Easy to work through with small modules, but a little more frustrating when working on a larger eLearn to have to go back and check the slide layout for all slides when only making edits to one page prior to re-saving to ensure the bug hasn't cropped up again.
I am referring to what you see on the network as the .story file. It is not, as you say, a singular .story file, it is a zipped file. I just changed the extension of one from .story to .zip and unzipped it. It is a rather small (1,200 kb, 1 slide, 2 pictures) file, and when extracted contains 16 folders, and 65 files. I say this to say that any sort of network hiccough, buffering pause, or stray quark flying through your network during the compression/decompression phase can cause enough of a problem to introduce corruption. That's why local saving, then uploading after the zipping (of the .story file as a .story file) is recommended. Please note that I am not saying the network is for certain the problem, only that it could be. It is possible that changing one slide is not what changes another slide. It might be that the second slide (because of something in the zipping and unzipping and traveling back and forth to the network) is slightly fuzzy, and opening it causes the changes. I'm saying it could happen, and you can't know for sure until you copy the saved file up and down, from local to network, rather than saving and opening directly to the network, and maybe not even then.
Of course, there is no guarantee that I'm on the right track, and there could be other causes that I know nothing about. But I think that's where I would look first. Also, I'd reinstall.
This is still happening, it has happened on my most recent project and I forgot all about the issue and used slide masters without realising the problems it could cause later on.
Now every time I load up my storyline file and start to make amends there will be a few slides that shift their slide master from one to another. As part of my routine I have to check each slide master on every slide before I publish, but the only way to stop this is to not use slide masters at all.
It also happens with projects I take over from other developers.
I'm not on any networked drives.
My IT policy backs up all local files on my hard drive to Microsoft OneDrive, a shared, synchronized drive. I am also experiencing this issue, but I fail to find a way to save locally without engaging the OneDrive upload cycle, as my USB ports and any external drives are locked out.
I can appreciate how perhaps saving the program on a network drive could cause the overall .storyline file to become corrupt. To be fair, even this seems like a bit of a stretch. But when considering Articulate Storyline and the 100s of features and elements that can be contained within a project, why is it consistently the slide master changing random slides when saving? Theoretically, the font size, type, layout are all very interchangeable, the sequence of slides in a project etc. It is only ever the slide master updating and changing random slides in a project that is the problem and I am convinced it's a bug rather than choosing to save to a network drive.
This may not be a solution, but I did find that one slide spontaneously changed to a different Master while I was working on the .story file. I tried to apply the previous layout, but it was no longer available as a selection. Only the default masters were selectable. So I closed the file and waited. After my OneDrive completed the upload that was auto-saved, thus synchronizing the file on my hard drive with the OneDrive, I reopened the file, and the slide was restored to the original Master layout. This suggests to me that it is futile to change slide layouts when this happens. Something else is going on. Perhaps file saving permissions are being violated during the automatic upload process.
I now get around this issue by saving my .Story file as one of two alternate names. If Version A is still being uploaded and file permissions are blocked on some slides, I Save As Version B. When the path is clear, I save B and Save As A again. That's my solution for now.