Revision control
What do people do for revision control? For example, would love to tag a prototype as revision XXX, so it can be handed off to the dev team but I can continue working on the prototype for future iterations.
The need is to lock it down after sign off and have some ability to reference it, all while not preventing me from marching forward. This would also let us say that this revision was signed off on this date. The output is what we want to control, not so much the file since the output is what the business and development team are working off of.
Any elegant solutions to this? I'd rather not create new files each time, that changes the posted URL and it is a big hassle. Best idea I can come up with is to copy the screen so I can work on additional changes. This seems like it can get messy and it isn't structured, depends a lot on individual discipline to maintain. I figure I can add something to the page that says "PROD | QA | DEV" to alternate between the versions. Or we can version control screenshots.
What are other people doing, or are we going about this in an atypical way? Am I missing something basic? We are standing up a complex enterprise web app so this single prototype will have a lifespan of 2-4 years as we mature and iterate the offering.
Hi Jerry,
Unfortunately we do not have any "Revision Control" feature, however, as a workaround you could use the "Teamwork" feature instead which shows the list of records of the actions that have been applied to the prototype.
Best,
Sonia Durán
Hi Jerry,
Unfortunately we do not have any "Revision Control" feature, however, as a workaround you could use the "Teamwork" feature instead which shows the list of records of the actions that have been applied to the prototype.
Best,
Sonia Durán
Have you thought about the idea of using something like Git (or SVN) for the file, similar to the idea of committing code? You commit to a working branch after you've made changes that need sign off and then someone can check out that branch, test/review/etc and then push to your master branch all while you keep working locally.
Have you thought about the idea of using something like Git (or SVN) for the file, similar to the idea of committing code? You commit to a working branch after you've made changes that need sign off and then someone can check out that branch, test/review/etc and then push to your master branch all while you keep working locally.
All, thank you for the suggestions. Thought I'd give an update with what I ended up doing...
The "Teamwork" feature seemed a little too complex/clunky especially for casual consumers who just want to see the prototype via a published URL without knowing about the prototyping tool.
I really like the idea of using source control such as Git, but again way beyond what our non-developer users would be willing to do. It also assumes that there are other users of the actual tool that would open the file directly, when in this case I am the only user of Justinmind and the only access others get is to publish a 'reshare' to a known link that exists on an internal wiki page.
What I ended up doing probably won't scale so well but for now should suffice. If I'm working on a new version of a page I create a duplicate and work off of that. I also add in additional buttons that give the user a choice to which version they wish to access. For example, if I'm working on a new variation of a dashboard page, the "Dashboard" button in the interface, when clicked, will display additional options (instead of going directly to the page), such as: "Prod", "Dev", "Concept". As things work their way through the pipeline I'll keep things linked up and updated. So once something gets into production I'll update the "Prod" link to point to the dev page, thereby making that the new prod version. If there are no more versions or concepts in the pipeline, I'll remove the extra buttons so that clicking on "Dashboard" will take the user directly to the dashboard page, in which the prototype version matches what is in production.
All, thank you for the suggestions. Thought I'd give an update with what I ended up doing...
The "Teamwork" feature seemed a little too complex/clunky especially for casual consumers who just want to see the prototype via a published URL without knowing about the prototyping tool.
I really like the idea of using source control such as Git, but again way beyond what our non-developer users would be willing to do. It also assumes that there are other users of the actual tool that would open the file directly, when in this case I am the only user of Justinmind and the only access others get is to publish a 'reshare' to a known link that exists on an internal wiki page.
What I ended up doing probably won't scale so well but for now should suffice. If I'm working on a new version of a page I create a duplicate and work off of that. I also add in additional buttons that give the user a choice to which version they wish to access. For example, if I'm working on a new variation of a dashboard page, the "Dashboard" button in the interface, when clicked, will display additional options (instead of going directly to the page), such as: "Prod", "Dev", "Concept". As things work their way through the pipeline I'll keep things linked up and updated. So once something gets into production I'll update the "Prod" link to point to the dev page, thereby making that the new prod version. If there are no more versions or concepts in the pipeline, I'll remove the extra buttons so that clicking on "Dashboard" will take the user directly to the dashboard page, in which the prototype version matches what is in production.
Replies have been locked on this page!