Re: User Interface Context

On Jul 12, 2012, at 3:01 PM, Andi Snow-Weaver wrote:

> To Bruce's point, I would remove "set of" from the beginning of the definition. 
> user interface elements and the presented information within a product that are available to a user at any point in time, where the set is limited to only those that can be reached using navigation commands within the product, and without using any activation commands. 
GV: that breaks the ISO definition rules.   UI Context is singular  -- so the definition has to be a single item.  If you remove SET then you break the ISO rule.  But it doesn’t change the definition -- and we can decide to break the ISO rule if we like I guess.  I always try to adhere to it.  

> What does "and the presented information" mean?

GV:  The user interface context includes both the controls and the information presented.  If you change all the information then you have a change of context - and a change of user interface context. 

> Is the case of an authoring tool, I assume it is the "thing" being edited. I don't see a problem there as long as the "thing" doesn't have any interactivity of its own while it is being edited. 

GV:  don't see a problem with what?  not sure I understand the caveat or question you are asking.    

GV:  The information being presented would include both information which is always there for an app, and information that changes with each use.  So if I open a document in an editor I have one user interface context.   If I close it and open a new document - I have a new user interface context.  What I do will have a different effect - and change a different document.    We checked this out and this works for all of our SC.  It also works for single window (no window) apps.  And it solves the problem Peter/Alex were trying to solve in that blocks of content that appear in different user interface contexts (different uses of the product) will be repeated blocks in different user interface contexts and would need a way to navigate past them (which of course all well designed programs do.   In fact we haven't thought of one yet that didn’t though we could create one if we tried). 
> 
> But in the case of a user agent, I assume the presented information is the "thing" being rendered (web page, web application, Flash application, PDF document) which might very well have it's own interactivity.
GV:  Correct.

> In this case, it feels like scoping in "the presented information" is going too far. When I'm tabbing and arrowing around in a web application rendered in the browser, am I in the browser UI context or the web application UI context?

GV:  if you can navigate freely among them then they are all part of your user interface context -- which is what you would expect. 

> It's very hard to draw the line there - the tabbing might be part of of the browser UI context while the arrowing might be part of the web application UI context.

GV:  the question isn't so much - are these all part of the same UIC - which they are - but who is responsible for what. 

That is why we include the word "Product" so that responsibility doesn’t bleed beyond what you are delivering. 
> 
> I would like to avoid the use of "product" as it implies something commercial. But I can't think of another term to suggest at the moment. "Application" is also limiting as it leaves out the platform UI.

GV:  We had the exact same discussion and finally came to the conclusion that we were probably going to have to just define 'product' in the introduction as the "output of any creation process".   As in "the product of his labors".   And say that commercial products are just one type of product.    A team in an agency might be tasked to create a program or a web site and the product of their work (what they deliver) would be a product as well. 
> 
> I think we will have to define "navigation command" and "activation command", find different terms, or explain them better in the notes.

GV:   I think you suggested "navigation command or mechanism"  and I think that is a good idea.

GV:  I think you are correct that to make this clean we should define both of those terms as well -- (Nav com or mech) and ( activation command (or mech?) or action?)

> Most developers, absent further explanation, would consider selecting a menu item to be a navigation command.

GV:  Activating a print command is navigation?  hmmm.  but I can see that  some might think some are -- so we need to define them yes. 

> You are navigating to a different part of the UI. Activation, in the software context, generally means taking some action that changes something - saves a document, saves changes to settings, submits a transaction, etc.
GV:  arent those all menu commands?

> Using this definition, selecting a menu item might be navigation (opens another menu or non-modal dialog box) or it might be activation (opens a modal dialog box). 
GV:  AH - you mean opening up a lower menu ?   yes that is navigation -- and is done with navigation arrows.  But the latter - would not be and this would be resolved by defining what navigation commands/ mechs are. 

thanks 

g


> 
> Andi