Utility for software systems specifications
The current UI of Quality Spy looks pretty simple at a first look:
This UI evolved from the very first version which looked like that:
With the very first version everything was perfect, because it only contained a single function. Editing and exporting the “RichSpec” was a simple task. Since the program was useful, it was subject to change and many more features were added:
After some time in the past I realized that those features are too much for the beginner, so I added options to enable this “expert functions”. By default all expert functions are disabled, so at the start it look’s almost like version 1.0.
What’s wrong with it
While the feature enabling is a great leap forward, I realized that the UI is still not perfect. The WYSIWYG editor for the RichSpec was fool-proof and simple. It was just one function. Now you have multiple functions in one page, which makes it more complex to use, but also limiting to extend. The features are not self-explaining and present no flow.
What I have in mind is a flow-oriented menu like it is used in Quality Spy:
(Wording is subject of discussion)
What is different?
The flow is now explicit. In the beginning you start to create the map. I’m not sure if this is a good wording. It’s the “RichSPEC” how I called it in the first version.
The generic link function should be completely obsolete. Either you add a sub-spec or you add an wireframe. I don’t think that it makes sense to add other images than wireframes, so let’s be specific about it. Call the function “linking wireframes”, not “Image Viewer” like now.
The Minispecs function is called stories here. Maybe that would make it natural to Scrum? I will not discuss it here for redesign, since it doesn’t exist except in a spec!
When progress tracking is on a distinct page we can optimize it much better for it’s use case. For example we can show a nice summary chart or better filtering options. All that stuff that can’t be added to the current editor in a useful way.
Also a big change is the restructuring of the source tracing function. Currently, setting the tracing IDs ist part of designing the spec, not quite intuitive. To make the function more comfortable IDs should be generated from the function name via a naming convention (“Reset Password” will be “ResetPassword” for example). Currently the source tracing needs a lot of manual work. You must copy & paste the tracing class into your project, it would be better to specify the relative target of the file and generate it when saving the spec.
Also one should think about enabling or disabling the function on a per-project basis like in Quality Spy.
Things to be done
CRUD vs. Task-oriented
I still have some doubt. On the one hand I think that there is room for improvement, but on the other hand the CRUD-oriented UI offers a very deterministic way for understanding and you can create your own workflow while the task-oriented UI only allows the workflow that is hard-coded into the program.
Maybe it could also be combined, so that you can have the task oriented UI as the default view, but if you want you can switch into a pure CRUD-view?
Have to think about that.
Check the current version at http://sourceforge.net/projects/richspeceditor/ and compare it with the ideas presented here. Is it an improvement?