gregorE's dashboard

Jira please! – gregorE, on March 18, 2009 17:24

Now you are just making me feel embarrassed that I did not notice that one. Thanks again Michael.

Thanks Michael, I thought i had tried that but I was using a / slash!

Peldi- I've been working with a 70-control mockup. I have noticed significant improvement since your 8/9 post. Here is a quick list of events that were slow, but are now much faster:

(1) Selecting 10 or more controls and attempting a copy/paste or duplicate action

(2) Selecting a large control, or several controls and attempting to move them (was especially slow trying to move these with the arrow keys, but now its very responsive)

Anyway, hope that helps, I'm now experiencing zero lag moving 70 controls.

I'm experiencing the same problems as Jeff. I'll send the XML to you as well in case it may help.

Thanks Peldi. Can't believe I missed the accordion when I went to look for it. I suffered from my own mantra that "users are stupid". I must get around to doing a usability test on the temptation to scroll past the leftmost option when a large horz scroll is presented. Anywho, the "quick add" is my friend now.

Re: Size by numbers, your assumption is correct, I'm struggling with this for the browser window control. Easier dragging below the fold would be a viable solution, but there is something to be said for the precise sizing of your workspace. – gregorE, on July 30, 2008 16:33

Great tool Peldi!
I'm currently leading a team of designers for an enterprise 2.0 company. I've been keeping my eye on the tool over the past month or so, trying to make a decision about implementing it within my organization. This "image upload" feature is especially interesting because it has the potential to solve a "custom controls" issue I have.

Besides the complexity problems, most of those "high-end" prototyping tools take so long to catch up with the "modern web". For most of them, adding a "tab control" is the mos "modern" element they can offer. Our application is community driven and uses lots of the trendy stuff: flash confirmation messages, tag clouds, accordions, sliding trays, animated loading dialogs, web tree controls, modal widows which dim the calling page, rich text rollovers, rich drop downs, and the list of ajax, jQuery stuff goes on. This stuff is hardly rocket science, or even that incredibly new, but if you have a large mockup tool with tons of dependencies, it takes longer to add new controls.

One of the things that is really making me want to implement Balsamiq is the speed at which you are adding controls. I feel like every time I revisit the demo there are a few more goodies that we use in our application.

My big question related to this discussion is:

Can (and will) this rate of new elements continue?

If the answer is YES, then my desire for custom controls goes down dramatically. For example, we currently we make use of the "accordion" control (like the one in outlook), but at the rate you are going I would expect it to be in the app by the time you respond to this post. The ability to stay "moden" with rapid control development is one of the biggest selling points of this application. If I were on the marketing team over there I would even consider adding that to my messaging. Its really hard for a complex app, like Axure for example, to keep up with modern controls.

I would guess from my old developer days that making robust control customization will slow down the progress of native controls, and Robert makes a good point that the edibility of your "built-ins" has probably spoiled users and perhaps set a benchmark that would result in a complex implementation for user-created objects.

I can't say that I would be too interested in the aforementioned idea of custom controls being available as one-off requests for additional cost. Nor do I think it is necessary. At an organization like mine, that would require approvals and POs and frankly too much time. If there was a control missing that we needed, we probably needed it yesterday, and this image upload (although not ideal) would serve as the workaround (with hopes that the control would be there by the next design iteration).

It's true that you will never be able to anticipate every control a user may dream up, but you don't have to. There are only so many "proven" elements out there that you could implement nearly all of them, plus some of the newer trendy ones.

So for what its worth, I would recommend:
(1) Shoot for a really complete control set and keep the image upload functionality as light as possible.
(2) Stay as up to date with the design patterns, and current web trends as possible by continuously adding controls that reflect today's UIs.

On the image management issue I would PROVIDE options to the user! It seems your user community is going to always be split on this b/c you really have two viable options, both with very good trade-offs.

Single file portability vs. File size.
Depending on the environment in which your are collaborating one trumps the other.

Just let the user pick. I might be collaborating on a corporate network and I want to use an absolute path over the corporate intranet, or perhaps images I'm serving from the public internet.
That should be an option at the point of save, along with embedding the images, along with including the images with relative paths in some sort of .zip.

If you have read this far I suppose it does not hurt to make one final request that is slowing me from pulling the trigger and buying this thing....
Can you provide an option to resize controls by typing the dimensions (in addition to dragging). The drag to resize does not work well when I need to make a really long page. This is a show stopper for some of our mockups that show comment lists (like this one) where we need to illustrate how things will look with some lengthy l.ipsum population.