General developer forum

might be interesting for you to see
http://tracker.moodle.org/browse/MDL-18970

Now that you got some data on user needs, I'll try to place attention on what I find relevant. But first I have to ask you to excuse me for making you do a User Experience practitioner's work. I realize from my experience that it can be really hard to concentrate at once on software engineering/programming and on the needs of the actual users, and really these are two separate fields. Still, anyone working on software needs to have an idea about learning the needs of users, just like an User Experience practitioner without any understanding what is possible to implement can be more of a burden than an asset to programmers.

One of the key questions on the more general behaviour of your app is

• whether it is for just editing single images or whether a single instance of the application can handle saving of multiple files at once.
  
• Or if the app can even have several images at once open?
  

The fact that you plan to initiate the drawing inside the rich text editor takes the complexity of this question up a notch.

• How should developers, who decide that in their module users should be capable of drawing, decide whether to just enable drawing or drawing inside a writing? (Are there contexts where drawing but not text is needed? With little children invoking a drawing application separately from within a writing application may already be too complicated.)

My gut reaction would be to keep your app simple as possible: have Moodle determine whether in a given context there can be several drawings or just one (and thus, just have a "clear image" button in your app, with a confirmation dialog).

I am thinking of having one instance of your simple drawing app, and then if there can be a number of drawings, the module developer can have a "add another drawing" button under the drawing app, to have another instance of your app started below the first one. And maybe also then have controls to remove - with confirmation - accidentally added instances?

This would keep complicated UI modality out from the drawing app itself - since the drawing app already lives inside a browser window which has modalities (tabs) of itself (and the browser usually lives within a multi-tasking environment which is another modality), too much modality within a web page easily creates extra confusion to users.

This is an example of a scenario where user data is useful. So, what we need to do is try to find the key scenarios which we want to support, and then balance the UI of the app to support the ones we find important. Let's take the first description of a scenario:

"One of the things that young students like to do is draw a picture and then write about it. This is also very helpful to our students who are learning a second langauge. It could also be used with other students to illustrate the points they are trying to make. "

So: Young students, and those learning a second language, could use a drawing to get started with writing, right? So in this scenario, the point is not really to create a picture to support existing text (as opposed to newspaper articles where pictures are there to support the main text content). Instead, students are encouraged to start drawing, and then tell about their drawing.

In this situation, just a text editor with a possibility to add images would a) be more complicated an UI than it needs to be and b) would actually communicate to the students to do a different thing than the teacher originally meant, which was to first draw a picture and then move in a sense to the next step (though being capable of still continuing to edit the image, too) to write about it. The ideal UI to fit this particular need would then seem to first have a drawing app directly on the page (probably for just one drawing without the capability to add another one). And below that drawing app, on the same page, there would be a text editing box, for writing about the image - and to avoid confusion, that text editing box should not have a button to add another image inside the text area.

An important aspect of this is that it is modeless (unless you count scrolling the page as a mode). You can go back and forth between writing and drawing, without opening and closing the drawing window and potentially worrying about saving the changes to the picture every time you want to go from drawing to writing and back again.

On the other hand, with the other scenario mentioned, "It could also be used with other students to illustrate the points they are trying to make" it seems clear that these students need to add their images inside the flow of text.

This also has to do with saving functionality. I think the ultimate goal is to have autosaving in Moodle and in the web in general so good that users really would not have to worry about saving their work with a second save button, but could just push the submit form button when they have finished working. (In some context, previewing before submitting button can be useful though.)

My post is getting long, but I hope you are getting a bit of an idea about how the answers are to be used. It is user research, so you don't take people's opinions at a face value, but try to understand their needs, in this case pedagogical needs, and derive how the application might best serve those needs. Like in the above, the needs don't necessarily translate directly to features, but to more subtle design decisions of the app.

(To risk ranting too much, this is exactly why user research and user experience design need to come first in any software development process - the experience of the user is not just an interface to slap on the finished app, but the needs of users can affect every layer of software design.)

An extra rant: It seems that the default TinyMCE rich text editor in Moodle 2.0 adds a huge distraction to users with those three rows of buttons. Though this is not your responsibility to think through, I am wondering if there really is an expressed need for more controls or could TinyMCE be stripped from all the controls that aren't there in the HTMLarea of 1.9? Or could the extra controls at least be hidden with progressive disclosure, to be shown only with the click of a "show advanced controls" button - like wordpress does?

While I appreciate the concept of having an infinite canvas, currently this possibility is out of scope for PaintWeb. Perhaps some time in the future.

buy cell phones unlocked cell phones

Thanks everyone for your ideas.

Before our features wish-list becomes too long, let's remember that the paint tool is Mihai's Google Summer of Code project i.e. three months work.

Mihai, I'd really like a very simple paint tool that works perfectly and that younger children can use easily.

We did think of realtime collaboration on a single drawing between multiple users. However, we have decided, as Helen pointed out, it's best we focus on the development of a simple, easy to use, online painting tool for children. Once the codebase of the paint tool is mature enough, it's definitely expected we can evolve further, up to the level of realtime collaboration.

Thanks to everyone for their feedback.