Suggestions

It would be helpful to be able to detect broken links when renaming screens during a refactoring. A Java-like refactor operation that automatically fixes the references would be way cool.

Screens should have links just like buttons and rectangles. When one screen automatically progresses to the next (e.g. a status screen with a progress bar that closes automatically immediately after the progress bar gets to 100%) It's a bit ugly to have to create a small rectangle on the screen just to implement that.

The tiny scroll "tabs" (not sure what the proper name is) that scroll the Palette window are a pain in the butt, especially at 1920x1200. It's a tedious waste of time trying to click on them with a mouse and nearly impossible with a touch pad. A vertical scroll bar seems like it would be worth the screen space.

Conversely the icons for the widgets are huge at that resolution, far bigger than they need to be. It'd be nice if it functioned like a Windows window, with a choice between small icons, large icons and a list/detail view.

It would be very helpful to be able to re-order the widgets in the Palette window. I'd like to be able to keep the most frequently used ones at the top rather than having to take my hands off the keyboard and reach for the mouse to scroll or filter.

Based on my first couple of hours of evaluation, I'll likely be buying a license. I've tried a bunch of other tools for UI mockups and this is by far the most usable and reasonably priced package I've found. Very well done, and having it integrated in Eclipse (which is where I "live" when I'm on the computer) makes it the best thing since sliced bread.

As Steven Wright says, "What was the best thing before they invented sliced bread?"

Hi Dan,

Thank you for your kind words and for all the suggestions! Please see my answers below.

It would be helpful to be able to detect broken links when renaming screens during a refactoring.

Dan, I added refactoring some time ago. I am not sure what's happening in your case. Please see this blog post with more details. If refactoring doesn't work for you as described there then try sending me a bug report using Window > Preferences > WireframeSketcher > Report a Bug:

http://wireframesketcher.com/blog/2010-11-18-refactoring-moving-and-renaming-files-safely.html

Screens should have links just like buttons and rectangles.

Dan, I think you are looking for storyboards. Storyboards allow you to create PowerPoint-like presentations. This is where you can arrange screens in the desired order to show the progress from one screen to another. A storyboard is created using File > New > Storyboard.

The tiny scroll "tabs" (not sure what the proper name is) that scroll the Palette window are a pain in the butt, especially at 1920x1200.

I am aware of the problem with palette scrollbars. Thanks for reminding me. I'll increase the priority of this issue.

Conversely the icons for the widgets are huge at that resolution, far bigger than they need to be.

Dan, you can righ-click in the palette and change some of its settings. You can choose small icons and change the layout.

It would be very helpful to be able to re-order the widgets in the Palette window.

This was suggested to me before. I also think automatic reordering based on usage frequency would be a nice touch. I am still thinking what's the best way to implement this. Meantime try using the Quick Add via Ctrl+Space.

I (stupidly) assumed there wasn't any refactoring because I didn't see anything in the Eclipse 'Problems' tab when I deleted a screen that was referenced by widgets on other screens. I'll see if I can reproduce it.

Sorry, I misspoke when I said "Screens should have links just like buttons and rectangles." What I meant was window widgets should have links just like button and rectangle widgets. I want to describe a status window that is displayed during transitions between two windows. The status window only has a progress bar and a 'Cancel' button widget on it. I can create a link from the Cancel button to the ActionCanceled.screen to illustrate that sequence but I can't create a link from the window itself to the next screen in the progression to illustrate that sequence.

The way I've done that for now is to create a rectangle in the lower right corner of the Window widget, make it rounded with a dashed outline (so it's not confused for an actual button) and set the link on the rectangle to the screen I want to transition to next. It'd be a lot cleaner visually and logically if there were just the standard little yellow icon at the bottom right of Window widgets to link to the next window in the sequence.

Thanks for the tips on the other bits! Small icons in a detail view is much better, though I wish it didn't force alphabetical order on the entries in the list. Ctrl+space will work after I'm accustomed to the widget naming conventions.

A question: have you considered exporting to XMI ? I ask because I had started prototyping screens in Enterprise Architect but the static nature of the diagrams made it less than great. It would be nice to be able to import my WireframeSketcher diagrams into a UML diagram though, so I can link widgets to requirements, domain objects, schema etc.

Thanks for the quick response!

Ah - I just spotted the Hotspot widget in your blog post from 2010/11/28! That will work for the screens, though I still wonder why screens don't have a link like other widgets since screens can appear without any other widgets on it (like splash screens and progress dialogs, or a full screen video window that is only closed when a key is pressed)

Dan,

You are right, I don't handle deleted screens. Maybe I could display a broken link icon instead of a regular one.

I'll consider adding a Link property for Window widget. But you are right, the Hotspot widget is another way to do it.

WireframeSketcher saves screens in XML format so it should be possible to read it and transform it to something else. Using XSLT stylesheets is one possible solution. I am not familiar with Enterprise Architect but perhaps you or some other user could contribute a simple tool that does the conversion.

In some cases it requires more than one link for a window. A hotspot would be a nice convenience but by no means critical.

I realized that after I started using the hotspot to link the windows. Progress dialogs sometimes revert to difference screens. For example a "Connecting to service..." window can link ahead to a "Connected" window or back to the "Login" window if the connection attempt failed. For activity like that I need two links.

I realize that screens in a .story have to be sequential for PDF printing purposes, but that doesn't mean the display has to be, does it? If the .story editing window allowed free-form positioning of the screens I think it would be more useful. If it allowed rectangles for grouping in packages/use cases it'd be even better.

Of course since most everything else I wanted was already in it I should probably phrase that as a question rather than a statement... is there a way to arrange the screens free-form? :)

I'm a little light in the XPath department. I wrote a few sample transforms using javax.xml but just trivial stuff. That does seem like a good way to convert from WS xml format to xmi. I might give it a shot at some point, right now I'm just enjoying making tremendous progress on screen definitions because I finally have the right tool for the job!

Okay I'm licensed now, where do I go to stomp my feet and demand better service and more features? :)

Seriously, thanks for the elegant solution to the problem of UI prototyping. I spent many frustrating hours evaluating various packages and I found a lot of overly complicated, expensive or poorly designed "solutions". WireframeSketcher would have been my choice even if it had been only a standalone product, when you throw in the Eclipse integration and the rapid responses in the support forum it's the winner by a mile!

Dan, thanks again for you kind words. Can I quote you on "testimonials" page?

Non-linear screen flow is something that I'd like to add. Here's another discussion on this subject with a possible solution:

http://wireframesketcher.com/forum/topic/23229/storyboarding_complexity?p2

The idea is to keep Storyboard Editor as it is but extend it with another tab which shows the flow in a more free-style manner. Screens can be rearranged graphically and links are visualized as connections between screens.

Still, in your specific case with progress window branching to two different screens, it's up to you to provide two hotspots that link to those screens. Perhaps you could use Callouts for that. Like this:

Let me know what you think. Do you see a better solution?

I agree with you, hotspots or callouts is the way to go for representing the passive/automatic transition from one screen to the next.

I'm trying to picture how the map you're talking about in the other thread would function. I think we're saying the same thing from two different perspectives. I'm looking at the current implementation thinking that screens do not need to be displayed in a linear format simply because they have to be printed in sequential order. The only difference I see from the current implementation (in extremely crude pseudo code) is something like this:

for (Screen screen : screenList)
render(x + increment, y, screen) increment += cellWidth

What I'm thinking is just letting display position control where they are rendered

for (Screen screen: screenList) render(screen.x, screen.y, screen)

...where screen.x and screen.y are determined by where the user positioned the screen objects on the display, not what order they appear in the 'screenList' collection.

A separate map would allow relationships between .screens to be defined, but I'm trying to think: what would those relationships would be used for in visual prototype? And if they are useful, would one map be enough?

The only thing that comes immediately to mind is the link in a map of .screens in a .story could represent transitions in some state machine defined by the implementation. I could see that being handy in some cases. However, if I could simply place .screens in arbitrary positions in the .story window, and if I could draw rectangles around arbitrary groups of .screen objects on that window then I could group them by the internal states they represent, or by package name, or by which future release each feature will be implemented or any other visual/logical grouping that I feel is appropriate in my UI visual sketch.

Feel free to quote, it's rare that a former submariner like me refrains from cursing long enough to be quotable! :)

Geeze I'm windy :p

A point I wanted to make is that "visual" is the key word to me.

If I can define what a .map represents, and if I can have multiple .map tabs for one .story collection, then that sounds much better than simply changing how .screen objects are rendered.

One issue a .map immediately brings to mind is the fact that a developer will likely want a .screen to know that it has been referenced from a .map. It seems to me like that requires that the .screen inherit properties from the .map objects that reference it.

Here's a "perfect world" use case example: User creates a .map tab named "Phase 1" and adds arbitrary .screen objects to the .map. The user defines a custom property for the .map "phase=1".

User does likewise for "Phase 2" and "Phase 3"

User creates another .map tab named "Startup Screens". User adds arbitrary .screen objects to it. User defines a custom property for the .map "state=startup"

When the user opens a .screen object to edit it, they can see the inherited custom properties "{map}.phase=1" and "{map}.state=startup" in a Custom Properties window in Eclipse

I think the "phase=1" sort of feature is the most important for a visual sketch of the UI, to be able to show the customer which of their screens will be delivered in each phase.

Dan,

I think what I am imagining is a little simpler than what you are proposing. In my view the storyboard editor would continue to exist as it is today. It will only be extended with an alternative view over screens that it contains. Like this:

You would be able to position screens freely, but relations between screens would be deduced automatically from screen links. So it's just a different and hopefully more clear view over the same set of screens that constitute a storyboard.