Forum > 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?"

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!

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.

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!

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) <br/>

 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! :)

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.