Hello everyone!
This summer I'll be working on a paint tool for Moodle (please read my proposal).
In the GSOC 2009 introductions forum, I have started an interesting discussion about usability and general user interface matters about the drawing tool with Olli Savolainen - please see the thread itself for further context.
As suggested, we will continue the discussion here. Anyone is encouraged to contribute. ;)
Here's my reply to the last message from Olli:
Olli said:
> Thanks. An example of a drawing UI that
> exhibits out-of-the-box thinking:
> http://www.atebits.com/scribbles/. That
> does seem to serve a more artistic use
> case than what is purposeful in Moodle,
> but throwing it in, in case it might
> inspire you. I guess you need a desktop
> app for that to perform well in terms
> of computing power, I don't know?
It's the first time I see this application. It sounds interesting, but screenshot links and the screencast link all fail. They won't work for me. So, I can't comment much, until I see more.
Sure, the more advanced the UI is, the more system resources are used. Obviously, a native application is much faster. Web applications need to be lighter than native ones.
The Photoshop CS 3+ interface is quite lovely, in my opinion. They allow an important amount of interface customization freedom - floating panels, dockable, stackable, etc.
You should check out 3D applications, like modelling tools: Mudbox, Modo, Zbrush and others. These are highly specialised native applications, featuring rather interesting GUIs, expansions on current metaphors and more. They are far the most "amazing" GUIs I have seen in real use.
> Why do you need 'new' button if the picture lives
> in a web browser? Isn't creating a new picture
> (=editor) more a job of the surrounding web
> page, in the sense that it is up to the context
> (=where you are in moodle) to define whether
> or not multiple images are even allowed?
You have a good point, but currently the button serves the purpose of clearing the current image (you can start over again with a "new" image). This is rather bogus at the moment. The idea is not to edit multiple images, just to start over.
Thing is, I don't think it's correct to remove this functionality, in any use-case. I agree some tweaking is needed. Any ideas?
Multi-image editing is not yet allowed by PaintWeb - nor is this planned for the summer. It shouldn't be *too* hard to do it, but... it's not yet needed.
> Also, I am wondering about the 'save' button. Web
> apps are going more and more to the direction
> that things are autosaved, and I think that should
> be the primary way of saving. As this app requires
> javascript anyway, AJAX-style autosaving should
> be available anytime the app is, right? You might
> want to keep the save button just to give the user
> the chance to make sure that it is saved, but I am
> not ruling out that it might be dispensed with
> altogether if autosaving can be made good
> enough in terms of its frequency and feedback
> to the user.
Again, very good point. I presume any implementation of autosave would rely on saving the state every 5 minutes (or some configurable interval). However, the user might want to save earlier, and coimplete the work. Besides, there's the benefit of making the user feel comfortable "hey, I know I saved the image". ;)
Another aspect needing given thought regarding autosave: how one would like it implemented? You surely don't want autosave to overwrite the original/real image you are editing - you still want a chance to cancel all the image edits. Then autosave needs to use a temporary file on the server, where to save the state of the image being edited. How about network use? Saving an image over the Internet is not as fast as saving an email in Gmail, every 5 minutes. One approach would be to save the history of actions performed by the user, then, upon recovery, re-execute all actions using the original image. This would allow very quick auto-saves, but slow recoveries.
Last, but not least, actions-based history is not yet implemented in PaintWeb. Thus, something like autosave will need to wait for it.
> If you want a UI where an uninitiated user is
> instantly confortable (you might not want this all the
> way, but I think you should go some way to make it
> easier), a minimal amount of buttons whose
> purpose is not clear to anyone, right away, should
> be in the toolbar. Or at least the more advanced
> ones could be grouped so that they are not in the
> way of the simpler uses of the application, which I
> suspect to be the common ones?
Suggestions for improved icon alignment / group are very welcome.
> The buttons I would say (and this indeed is
> subjective) are clear are (from clearest to fuzziest):
>
> - text tool
> ...
Eraser size is determined by line width (hehe, it's completely unintuitive for now). This must be fixed. Why the line width? Because the eraser is actually the pencil tool with some tweaks.
Good point about merging the poly tool with the line tool. Will do it. Thanks!
The "move/drag" tool is half-baked for now. It needs improvements: it should be disabled when the image fits in the viewport, and it should be usable at all times when holding down the Space key, like in Photoshop.
I would like to keep the Bezier curve tool, since it allows users to draw something they can't with other tools.
Maybe you could provide me with additional feedback/thoughts on the actual usability of the drawing tools themselves.
Thanks again, Olli, for a really well thought-out reply. I appreciate your valuable feedback.