With Unqork’s Module History, users can access a detailed (and revertible) version history of changes along with the ability to provide additional context for any changes they make. 

 

One of Unqork’s key strengths is its support for effective collaboration between colleagues who aren’t necessarily in the same department, the same office, or even on the same continent. The platform helps organize the input of multiple “Creators” through a detailed digital record of every saved version.

A single Creator may find this function a useful means to organize their work, but it can be absolutely invaluable when many teams are involved. One Creator, for example, may make a small change to a module, but one of their colleagues may discover that change doesn’t jive with another part of the application. Before the colleague can make the fix, they will have to investigate the what (i.e, exactly what changes were made that caused the problem), the why (i.e., what caused the original colleague to make these changes—perhaps it was to fix a different issue which will still have to be addressed), and the when (this is important to determine, so the team can decide which historical version of the module is stable and therefore safe to revert back to). 

This investigative process can end up being a huge tax of resources, particularly when dealing with complex applications with thousands of historical versions and dozens of collaborators. 

The good news is that Unqork provides an elegant solution to address these challenges while maintaining the platform’s collaborative and flexible properties. With Unqork’s Module History, users can access a detailed (and revertible) version history of changes along with the ability to provide additional context for any changes they make. 

Change, Made Easy

Change is inevitable. This is true in life and in custom software development. While you can’t go back on past decisions in life, you can with Unqork. 

To access Module History in Designer, Creators need only click on the clock icon in the top right-hand corner to reveal a detailed record of past saved versions of that module. This will prompt a new window, which provides a view to each saved version along with a timestamp which Creator made them. Here, you can even directly compare two different versions to locate the differences—the system will even highlight any components that were added or deleted between the two versions (a “diff”). Even better, Creators can generate a link directly to that specified diff to share colleagues for their input. 

(And, of course, if needed, creators can simply restore a past saved version of a module.)

Beyond simple version control, Module History allows creators to add useful color and context to any and all changes they make. For example, Creators can: 

Mark specific versions with a star icon, which can be used to designate a stable version that can be easily reverted to before moving forward with an experiment or iteration.

Rename versions to add more description. By default, versions are named with their timestamp, but users can provide more context with a more illustrative name, e.g., “UI experiment 2.”

Attach virtual notes to accompany that change. These notes provide Creators with the opportunity to write a summary of the change or call-out specific updates. 

These forms of additional Creator-generated context can be invaluable when making edits/fixes to a system. Even better, Creators can conduct a search to identify versions attached to a specific keyword used in the version names or attached notes (e.g., “sprint 3” or “GDPR” or “forked”).

Module History provides a safety net of sorts. It provides organizations with the freedom to experiment and innovate with the knowledge that they will be able to easily revert back if any of those experimentations go awry.