An idea for a killer example

[Trygve Reenskaug]

An idea for an example:

Task:
To create a widget for for a smart form where the user can change the values of named fields, e.g., as in a property sheet, an e-shopping order.

Solution:

1. Use a draw program to draw the form with its named fields.
2. Create a context and let it automatically map each field to a role.
3. Write role methods to make the form smart.

This example is easy to understand. There is only one new class, the context. There is no problem with finding the objects, classes, roles.

I'm working on an implementation with texts and buttons. I will report back if I succeed or hit a brick wall.

Caveats:

1. Any draw program can be used as long the context can access its draw elements.
2. The interesting draw elements have a accessible values as in text fields.
3. Some fields may also trigger events, e.g. accept, cancel.

--Trygve

[Andreas Söderlund]

Hello Trygve, nice coincidence! I've spent the last week tinkering with something that I feel is very similar, a CMS. The outline:

Task:

Make a CMS where content can be changed in real-time using content editors.

Solution:

Let a programmer create editors for various content, for example Markdown or Image gallery. An editor will both display and edit content.

Define areas on a webpage with content that will be displayed by an editor.

When an area is selected for editing, the editor will appear in a panel to the right, allowing real-time editing.

A Context will handle the interaction between areas, content, current editor, etc... 

The "content" is a very simple data class, the rest is just interactions upon it.

Design-wise, I think it's time to use the large screen resolutions for real. A panel can easily be placed beside a webpage without disturbing the layout, and another advantage is that the editing becomes relatively "modeless".

Got sidetracked the last day so I don't have much to show yet, but I'll keep you posted.

/Andreas

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Andreas Söderlund]

Sorry Trygve, I didn't want to hijack your thread, just got excited about the similarities. I'll post about the CMS in another thread after this.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.
To post to this group, send email to object-composition@googlegroups.com.

[Egon Elbre]

On Wednesday, 18 February 2015 14:23:07 UTC+2, Andreas Söderlund wrote:

Hello Trygve, nice coincidence! I've spent the last week tinkering with something that I feel is very similar, a CMS. The outline:

Task:

Make a CMS where content can be changed in real-time using content editors.

Solution:

Let a programmer create editors for various content, for example Markdown or Image gallery. An editor will both display and edit content.

Define areas on a webpage with content that will be displayed by an editor.

When an area is selected for editing, the editor will appear in a panel to the right, allowing real-time editing.

A Context will handle the interaction between areas, content, current editor, etc... 

The "content" is a very simple data class, the rest is just interactions upon it.

Design-wise, I think it's time to use the large screen resolutions for real. A panel can easily be placed beside a webpage without disturbing the layout, and another advantage is that the editing becomes relatively "modeless".

Actually I think the "modeful" for regular users is more comfortable - e.g. I double-click the item and edit the content and when I unfocus the item and the change is committed (alternatively press Escape to cancel). Of course a panel for adjusting different properties of the item is probably useful.

[Andreas Söderlund]

Drifting already, so changing topic. :)

I assume you mean the mode for either a modal editor or the switch to an inline editor, replacing the content temporarily? Actually modes should be avoided because they can confuse and/or frustrate the user, and this is what I'm trying to solve for CMS's. Jef Raskins The Humane Interface is a book describing this issue in great detail. I also just finished reading The Design of Everyday Things which has a more RL approach to modes, but nevertheless the same conclusion.

/Andreas

[Trygve Reenskaug]

Please stay on the same thread. The subject applies equally to both our projects and there can even be some cross-fertilization.
Are you contemplating that the editor will edit a role method?

--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

[Andreas Söderlund]

Ok, I deleted the repost. Sorry for the confusion!

I was thinking that the editor will edit the role "content", but not exactly edit a role method? Can you give an example?

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Egon Elbre]

On Wednesday, 18 February 2015 15:03:14 UTC+2, Andreas Söderlund wrote:

Drifting already, so changing topic. :)

I assume you mean the mode for either a modal editor or the switch to an inline editor, replacing the content temporarily?

Yes, an inline editor.

 

Actually modes should be avoided because they can confuse and/or frustrate the user, and this is what I'm trying to solve for CMS's. Jef Raskins The Humane Interface is a book describing this issue in great detail.

As far as I know, most graphical tools are modeful. I.e. move/rotate/draw/bezier... etc. So the question should be rather what confuses and what doesn't. A broad statement that "modes" is not good. 

When you mean, getting the same output from the same input... I totally agree with that. But most browsers, programs fail to do so. With one exception being the terminal (mostly).

Anyways...

The confusing part about modes is that you must understand where the mode came from - and how to get out of it. For example some mobile applications have a panel that can be pulled from the left side - it's mostly obvious where it came from, especially when it's properly animated. Of course the intuitive thing to close it is to do the action in reverse. However if that didn't work, then that would be confusing...

Also, every professional/powerful tool expects some degree of learning - so simply because a person can't use something the first time-around doesn't mean it's bad... it means it has a higher learning-curve...

+ Egon

[Andreas Söderlund]

Egon, I'm not in the mood for arguing and you seem to have made your mind up, so by all means, enjoy your understanding of modes. The books I mentioned opened my mind to a different view (including the area of "learning-curves"...)

/Andreas

[Egon Elbre]

On Wednesday, 18 February 2015 15:23:52 UTC+2, Andreas Söderlund wrote:

Egon, I'm not in the mood for arguing and you seem to have made your mind up, so by all means, enjoy your understanding of modes. The books I mentioned opened my mind to a different view (including the area of "learning-curves"...)

I indeed, I haven't yet read those books - so my definition of a mode might be different from the book. 

From a summary (http://nitpicker.pbworks.com/w/page/12451253/The%20Humane%20Interface): 

Modes exist where the same gesture yields different results depending on system state at a time when your attention is not on system state. In the presence of modes, you will sometimes make mode errors, where you make a gesture intending to have one result but get a different and unexpected result, distracting you from your task.

Is editing a different paragraph a different "mode"?

Is moving the text cursor to a different place switching "modes"?

Basically, I really don't see "modes", but rather different ways of interacting and the properties of interacting - difficulty, error proneness, distractiveness, preciseness, attentention movement, destructiveness...

The more destructive an interaction is, the less error-prone it should be.

How often you interact in a specific way means how easy it should be.

How long you do an interaction determines whether switching to a different way of interaction is useful.

Switching "modes" means that some interaction becomes easier and some other interaction longer/harder/impossible. Of course there is cognitive load involved in switching the "mode". This means the benefit you get from better interaction should be bigger than the cognitive load involved. Of course you can get habituated to switching modes as well, but it will take longer time.

case A having a separate panel for editing some item

1. you click on the item you wish to edit

2. you look at the panel where the editing is happening

3. you click at the location that you wish to edit

4. you type something

(although, 3. step also can be avoided, but the searching for the exact point is more difficult, which would mean you also need a clearer cursor which would cause more distraction).

case B double clicking

1. you double-click/select the place you wish to edit

2. you type something

(this assumes the modal editing doesn't move the items on the screen, if the things start to move then it's probably more distractive than the case A)

Which is better... from my own experience, if executed well, I prefer B, if not then A. It's probably better to code both versions and try the differences.

Anyways... I'm not for nor against "modeless" interaction - simply arguing that they are poor analysis subject because they take a binary view of interactions.

I'm not attacking the book either, judging by the summary, all the points seem reasonable. I added the book to my reading-list so eventually I will get to actually reading it.

+ Egon

[James O Coplien]

On 18 Feb 2015, at 14:17, Egon Elbre <egon...@gmail.com> wrote:

As far as I know, most graphical tools are modeful.

... and most software designers are clueless about mental models, modality, focus and locus of attention, GOMs analysis, and the things that really matter. Most programmers focus instead on polymorphism, coupling and cohesion, number of methods in the interface, and (horrors) lines of code.

Build a humane program. Raskin boils down good design to two things 90% of the time: 1. Avoid modes; 2. Build a monotonous interface (there is only one way to do any given thing.) This has all kinds of repercussions, such as not allowing interface customisation.

I think we try to underscore this point in the Lean Architecture book as well.

Avoid modes. Completely. They're evil.

[James O Coplien]

On 18 Feb 2015, at 15:35, Egon Elbre <egon...@gmail.com> wrote:

so my definition of a mode

This is a very (very) standard concept in UX. I don't understand how you can have "your definition of a mode." Your explanation suggests that you are unclear about what modes are. I suggest that for the sake of effective conversation you learn more about what the term means and what it bodes for the quality, or not, of your product.

[Rune Funch Søltoft]

> Den 18/02/2015 kl. 14.17 skrev Egon Elbre <egon...@gmail.com>:
>
> As far as I know, most graphical tools are modeful

And we are all subject to take biased decisions based on what we think most others believes. This has been studied a lot and used a lot. Eg in Minnesota they reduced tax fraud simply by advertising that more than 90% complied but it has also been shown that presented with something that's obviously wrong most people will believe they are at err if before asked someone else confidently supports the erroneous believe (regardless of what that believe is). My point is "I believe most ... does ... " is not an argument for anything. It's rooted in the automatic thinking process rather than the reflective. The reflective would highlight the advantages and reflect upon why they are a result of the proposed approach. Eg answering:
If the user is not confused and the program has no modes how would following the consensus you describe that modes are "the thing" improve the user experience?

[Egon Elbre]

On Thursday, 19 February 2015 11:57:00 UTC+2, Cope wrote:

On 18 Feb 2015, at 15:35, Egon Elbre <egon...@gmail.com> wrote:

so my definition of a mode

This is a very (very) standard concept in UX. I don't understand how you can have "your definition of a mode."

Mainly, because I haven't seen what is the "standard definition of mode". I haven't done proper research into UX books. The definition in the wiki and the summary were very broad.

 

Your explanation suggests that you are unclear about what modes are. I suggest that for the sake of effective conversation you learn more about what the term means and what it bodes for the quality, or not, of your product.

I agree... do you know any books that have those definitions outlined and well explained, so we can have the same vocabulary.

[Egon Elbre]

On Thursday, 19 February 2015 12:27:41 UTC+2, Rune wrote:

> Den 18/02/2015 kl. 14.17 skrev Egon Elbre <egon...@gmail.com>:
>
> As far as I know, most graphical tools are modeful

And we are all subject to take biased decisions based on what we think most others believes. This has been studied a lot and used a lot. Eg in Minnesota they reduced tax fraud simply by advertising that more than 90% complied but it has also been shown that presented with something that's obviously wrong most people will believe they are at err if before asked someone else confidently supports the erroneous believe (regardless of what that believe is). My point is "I believe most ... does ... " is not an argument for anything. It's rooted in the automatic thinking process rather than the reflective. The reflective would highlight the advantages and reflect upon why they are a result of the proposed approach. Eg answering:

I agree... I probably didn't properly explain what I meant by "graphical tools". I meant programs such as Photoshop, Illustrator, Inkscape, Synfig, GIMP, Sketchup, Blender, Spine, Spriter...

And those programs have a concept of tool e.g. "move", "rotate", "select", "scale", "pencil", "bezier" etc, they significantly alter the way what the input from the user does. As far I can see, all of those can be considered as different modes of operating. If that doesn't classify as program being in a different mode - then I'm really confused what "mode" means.

http://en.wikipedia.org/wiki/Mode_(computer_interface)

If the user is not confused and the program has no modes how would following the consensus you describe that modes are "the thing" improve the user experience?

The only way is to experiment - i.e. what feels better for the end-user.

I couldn't imagine a "graphical program" with 100 tools being modeless and quasimodes could introduce significant hand pain because of having to hold down some sort of button. Of course foot-pedals would be an option, but I cannot see how that would improve the situation significantly.

+ Egon

[Egon Elbre]

I've experimented with quasimodes in a tablet/mobile interface for drawing diagrams... using such interface introduced problems with holding it; i.e. you needed to hold it with your one hand and simultaneously control some buttons with it. The heavier the device is the more problematic this becomes. This is mostly fine with mobiles, but you start using up screen estate a lot. Also one handed use becomes totally impossible.

Although when having the tablet stand up on the table - it's pretty nice to use.

+ Egon

[rune funch]

2015-02-19 12:10 GMT+01:00 Egon Elbre <egon...@gmail.com>:

I couldn't imagine a "graphical program" with 100 tools being modeless

Since you've just equated "tools" and "modes" that makes sense. But what if the application was designed so that that equation would be false? I believe that BabyIDE is an example of that. There are several ways in which to look at the same artifact using different "tools" but to my knowledge they're not tied to different modes

[Egon Elbre]

My understanding is that, tools are a subset of modes. But, I don't believe that they are equal.

http://www.usabilityfirst.com/glossary/modal/

There are two important parts here, the

1. how the program behaves

2. how the user thinks, how the program behaves

If the mode changes (behavior of the program) are always in sync with the person, then there isn't a problem with using modes. The problems start happening when the mode changes distinctly from the human - e.g. accidentally pressing the wrong button or something else causing the change. Now the amount of disruption caused by it, depends how jarring the mode change is and how quickly can the person recover from it.

If it's hard to recover - e.g. such as in vi, then there is a problem.

If it's easy to recover, e.g. clicking on a wrong link in a web page, then usually the back-button can get you back nicely... although still not perfect.

In a similar fashion, typing a wrong letter (usually) isn't a big issue, because you can simply press backspace.

The problem isn't the mode change - the problem is the "mode error"... you don't want mode errors, and if they happen you want to be able to recover from them easily.

The benefits of having a mode must overweigh the "mode error" issues.

+ Egon

[James O Coplien]

On 19 Feb 2015, at 11:57, Egon Elbre <egon...@gmail.com> wrote:

Mainly, because I haven't seen what is the "standard definition of mode". I haven't done proper research into UX books.

1. You might start now. It sounds like you're working in this area, and if you are working this area and don't understand modality, you'll be viewed as a doofus.

FWIW, I think that's what's going on here.

2. In the mean time you might save yourself some trouble by not arbitrarily substituting your own meanings for broadly accepted bases, substantiated by sound psychological research.

[James O Coplien]

On 19 Feb 2015, at 11:57, Egon Elbre <egon...@gmail.com> wrote:

I agree... do you know any books that have those definitions outlined and well explained, so we can have the same vocabulary.

Er, I think someone has already pointed out Jef Raskin's "Humane Interfaces." That would have been a good point to get the book and look it up.

Raskin's bibliography in turn can lead you into the foundations in cognitive psych, neuropsychology, and perhaps the research case studies.

[James O Coplien]

On 19 Feb 2015, at 12:10, Egon Elbre <egon...@gmail.com> wrote:

The only way is to experiment - i.e. what feels better for the end-user.

No, there has been a heck of a lot of ground covered here to establish that things don't work. No amount of experimenting is going to use your selection of colour schemes to enable a totally blind person to interact with your program.

Instead of standing on your tiptoes, stand on the shoulders of giants.

[James O Coplien]

On 19 Feb 2015, at 12:10, Egon Elbre <egon...@gmail.com> wrote:

then I'm really confused what "mode" means.

Yes.

[James O Coplien]

On 19 Feb 2015, at 12:17, Egon Elbre <egon...@gmail.com> wrote:

I've experimented with quasimodes...

Quasimodes are not modes; it's just that the feedback is kinesthetic (usuallly) rather than through the visual cortex. That brings them into the locus of psychological attention. Again: quasimodes are not modes.

[James O Coplien]

On 19 Feb 2015, at 14:08, Egon Elbre <egon...@gmail.com> wrote:

Since you've just equated "tools" and "modes" that makes sense

My social network analysis environment uses many tools (in the MVC sense). But that hardly makes it modal.

[James O Coplien]

On 19 Feb 2015, at 14:08, Egon Elbre <egon...@gmail.com> wrote:

If the mode changes (behavior of the program) are always in sync with the person, then there isn't a problem with using modes.

Then, by definition, it is not a mode. A mode, by definition, is the possibility of what we usually call side-effects that happen outside the end user's locus of attention. ("Locus of attention" is a psychological phrase that relates to identity and consciousness; it is often tied to the visual cortex, but need not be.) "Locus of attention" *IS* the person's consciousness. So if the program is in synch with the program's consciousness then, by definition, there is no modality.

So the above sentence makes absolutely no sense.

[Rune Funch Søltoft]

> Den 19/02/2015 kl. 14.08 skrev Egon Elbre <egon...@gmail.com>:
>
> The problem isn't the mode change

The way I want to use programs are often blocked by modes because it makes it impossible for me to work in both "tools" simultaneusly

[Egon Elbre]

1. You might start now. It sounds like you're working in this area, and if you are working this area and don't understand modality, you'll be viewed as a doofus.

FWIW, I think that's what's going on here.

I have a lot of things on my reading list.

And the best I can describe my relation to it is that I tinker in this area.

 

e.g. few dabblings in touch based menus:

This example is how to create a "discard" "close", "hide", "save" etc. without having to resort to explicit touch gestures but also to protect against accidental "closing" of an unsaved document. Basically the "discarding" would require the more difficult gesture while, "save" and "close" would be easy. This is also trying to get rid of the "are you sure you want to close this thing".

http://jsfiddle.net/egon/5JAmK/embedded/result/

This is for navigating a touch based menu, that should be faster to use and better against accidentally going into wrong submenu. Of course care must be taken not to start moving things around constantly.

http://jsfiddle.net/egon/CXFL5/embedded/result/

This was an experiment in building a touch interface for diagram drawing that shows as little as possible and only when necessary.

http://fuse.egonelbre.com/

PS. these probably have been done elsewhere that I don't know about.... and I'm not saying I'm the first person to do those.

2. In the mean time you might save yourself some trouble by not arbitrarily substituting your own meanings for broadly accepted bases, substantiated by sound psychological research.

Sorry, that was not my intention. I can understand that some of my vocabulary can be wrongly learned due to lots of information - e.g. dictionary definition not completely aligning with some specific meaning. By no means I'm trying to say my definition is better, far from it... For the sake of clarity in discussion I often try to explain what I mean by certain words, because I know that misaligned definitions can lead to different conclusions and understandings. 

tl;dr; By explaining, I'm trying to make my meanings understood; and not trying to define them differently.

I will adjust my definition of "mode" when I can finally understand what it actually means in this context. Incrementally changing my definition would confuse other people more.

 

Then, by definition, it is not a mode. A mode, by definition, is the possibility of what we usually call side-effects that happen outside the end user's locus of attention. ("Locus of attention" is a psychological phrase that relates to identity and consciousness; it is often tied to the visual cortex, but need not be.) "Locus of attention" *IS* the person's consciousness. So if the program is in synch with the program's consciousness then, by definition, there is no modality.

So the above sentence makes absolutely no sense.

By that definition, if I observe pressing caps-lock then it's not modal?

I saw "mode" as being distinct setting that determines how a program behaves given some user input.

So it seems the standard definition is as in "operating mode of the user"? And "modeless" meaning the locus of attention shifts as little as possible?

Anyways... I'll just explicitly state that I currently have the wrong definition of "mode" and will fix it as soon as I have time. I'll try my best to avoid arguing over it.

No, there has been a heck of a lot of ground covered here to establish that things don't work. No amount of experimenting is going to use your selection of colour schemes to enable a totally blind person to interact with your program.

I'm not suggesting throwing out old experiments nor lessons learned from them. Neither am I suggesting experimenting with random things - when some experiment fails, you try to understand why it failed, and experiment with something that wouldn't cause the same failure.

+ Egon

[James O Coplien]

On 19 Feb 2015, at 20:47, Egon Elbre <egon...@gmail.com> wrote:

By that definition, if I observe pressing caps-lock then it's not modal?

In some implementations caps-lock creates a persistent state that is outside the users locus of attention. If Caps Lock changes the shape of the insertion cursor, then it need not be modal. If it only illuminates a lamp on the keyboard, it is likely modal because that lamp is outside the user's locus of attention. If it has no manifestation of state, it is definitely modal.

The degree to which techniques (such as the cursor change) illuminate the effects of modality certainly can be measured, but in most cases that's overkill.

There is also the question of context. All input is subject to learning — or not. You treat modality differently in an occasional-use interface (a Disneyland theme part kiosk for finding directions) than in a repetitive high-use interface (for a telephone attendant to semi-automatically connect calls).

I saw "mode" as being distinct setting that determines how a program behaves given some user input.

You have mentioned many things that you see and many of your own definitions. This is another one. It is not quite right. And it's overly simplified.

Please read Raskin.

Signing off from this thread.

[Egon Elbre]

On Thursday, 19 February 2015 21:47:14 UTC+2, Egon Elbre wrote:

1. You might start now. It sounds like you're working in this area, and if you are working this area and don't understand modality, you'll be viewed as a doofus.

FWIW, I think that's what's going on here.

I have a lot of things on my reading list.

And the best I can describe my relation to it is that I tinker in this area.

Anyways I bumped everything else on my reading list down a bit and read Jef Raskin.

So what I gather from that book + in the article referenced in "Humane Interface" (http://dl.acm.org/citation.cfm?id=67243.67248).

Basically, I figured out what my problem was, I thought that "mode" and "modal" were distinct in their meaning. I thought that "mode" referred to the definition in 3-2 and "modality" referred to 3-2-1.

+ Egon

[Hai Quang Kim]

question: as I logged in as different users, the application gives me slightly different interface for the same screen. Is that a mode?

In http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782

The author considers it as a screen mode.

/quang

[James O Coplien]

On 05 Mar 2015, at 10:25, Hai Quang Kim <wan...@gmail.com> wrote:

question: as I logged in as different users, the application gives me slightly different interface for the same screen. Is that a mode?

It certainly violates habit formation, which is the deeper foundation of good interfaces. Raskin is very much against customisation of interfaces for this very reason.

[Hai Quang Kim]

The book is quite old, and the application style is also quite old.

It is a bug tracker app. In the same screen it has 'create', 'close' buttons.

eg. only QA can create bug. and only developer can close bug.

/quang