layers of use

nice work peter,

our company is in search for a sketching tool and i'm favoring your product. we have to integrate it into agile processes and i would like to ask your opinion on having changesets, applicable on screen xmls. function based pure wireframes could form base model on which developers and designers could work paralell. having controlls (thus navigation and functions) fixed, developers can code early enough while ui designers are producing shiny prototypes for customer reviews. guess that is also possible by xml afterprocessing but upcoming program feature just sounds better :)

advanced storyboard editing sound promising too.

cheers, arpad

Arpad,

Thank you for your kind words! Could you give me several specific examples on what you are looking to achieve? I am having hard time understanding what your use cases are.

What concerns XML post-processing, the answer is yes, this is possible. Here's the XML format specification that you need for that.

hi peter,

A simple case: Imagine a standard login screen for a web application: you have a title, two inputs with labels (name, password), a forgotten-password link and the sign-in button. One can sketch it with few standard widgets and it clearly defines login(name, pw) and sendPwByEmail(name) functions. This would be the [base/functional screen].

Adding it to specification, (server side) programmer1 can proceed creating persistency layer and implementing login and sendPwByEmail services.

Meantime (UI) designer1 is adding some graphical elements to the screen (background, logos), he is also reordering input fields, replaces the button with a customized png, adds help text and so on, to have charming look for presenting it to customer. All his changes could be saved incrementally (also tracking customer mind changes) as [design changesets]

(javascript) programmer2 is arriving and he adds some js validation notes and assets to [base screen] which forms the [client side changeset]

programmer1 is working on his services all the time relaying on [base screen]. his changes are reflected to designer1 and programmer2, but he is not bothered with their changes.

(lead) programmer3 might want to see all in one, checking if all participants are sticking to naming conventions and the overall result is satisfying.

Add more complexicity, navigation, people, and you probably got the idea behind the need for having different views of wireframes in opposite of branches.

I was also thinking on hidden attribute for widgets (at least for decoration elements) - that would be partial but easy solution.

regards, arpad

Arpad,

Thanks for your explanation. I see it better now. However it all seems quite complex for a little wireframing tool like WireframeSketcher. Still, you might want to look at two things:

• Version control plugins like Git or Subversion for version tracking
• Custom id and data properties that you can edit for each widget using the context menu. You could really put anything inside the data property as long as your XML post-processing tools can interpret it.

Hi Peter,

thanks for for your replies, I've figured out how to use it for our purpose. company wide usage is still an issue but I've got a license to use sketcher in my project.

have a nice day, arpad