dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]flexible for users, or flexible for developers? (was Re: Use


From: Jonathan P Springer
Subject: Re: [DotGNU]flexible for users, or flexible for developers? (was Re: User Interfaces)
Date: Sun, 30 Jun 2002 13:05:29 -0400
User-agent: Mutt/1.4i

On Fri, Jun 28, 2002 at 12:21:26AM -0500, S11001001 wrote:
> Adam Theo wrote:
> >I've been thinking about user interfaces today, dredging up alot of my 
> >old ideas. Here's what I think the best option is for user interfaces of 
> >the future to be built on.
> >
> >I think there needs to be a universal, platform-independant was of 
> >defining a user interface. Probably using an XML document to define it 
> >for each application, and they all share the same XML vocabulary so they 
> >can be interchangeable. This is what Mozilla has done, I believe, 
> >although I forget the name or the details.
> 
...
> >However, HTML sucks, and as many have stated was never meant to deliver 
> >applications. HTML cannot be used. But a HTML-inspired, XML-improved, 
> >well thought out spec could be created that used a web-like interface to 
> >allow maximum flexability to developers and users.
...
> Perhaps this is possible when `platform-independent' means working on 
> all different OSes, but expecting the same thing when it comes to a 
> computer (screen, keyboard, mouse, proc, HD, filesystem, software can be 
> installed), in the sense that most people say `computer' (after all, 
> most people don't think of their TVs as computers, or their calculators, 
> etc. But when you start going as far away as a PDA, things change. The 
> expected user interface changes. Or what about accessibility devices? So 
> you have to let the implementation (of the UI displayer) decide alot of 
> what should be happening. However, this preempts the whole "flexible for 
> developers" thing. To allow the platform to be flexible, we must limit 
> what the developer can create, so as to guarantee a consistent (and 
> uncomplicated!) user experience.
...

This all got me to thinking back onto one of my rants on HTML and Web
designers.  The nutshell of the rant was that the "designers" took a
beautiful WYGIWYG means of conveying information and using more tables
and extensions than a restaurant with one power outlet managed to
pervert it into yet another exact presentation tool that doesn't quite
work for everyone.

The thought led me to the realization that UI paradigms need to be
similar to the XML/XSLT-->HTML paradigm.  To wit, the particular user
actions required to interact with the application must be independent of
the interface used by the application to perform that interaction.

An example would be the ubiquitous picklist  where the user is expected to 
pick one (and only one) item from a list of options.  Off the top of my head,
this could be implemented in a GUI as a dropdown, dial, radio button list, 
or scrollbox with one highlight allowed.  Adding in portability
concerns, one could implement it in curses as emulation of the above.
To go to an extreme, if one is using a block-based terminal (e.g. 3270),
the best way to implement is as a numbered menu where the user enters
the number of the appropriate choice.

This problem comes as a surprise to no-one.  In fact the entire "themes"
movement is based around the realization that certain operations (aka
widgets) can be represented in multiple fashions.  Themes, however, seem
to me to still be too oriented toward powerful GUIs and presentation.

With the advent of use-case-based methodologies (e.g. UML), there's an
opportunity to introduce another layer of abstraction.  An application
becomes a web of interactions with the users.  These interactions are
well-defined, however their presentation is left to a tool.  ("I need
this transaction to consist of pick-operation A, entry operation B, and
confirm operation C".)  The presentation component translates the
actions into the appropriate representation (picklist, string widget, OK
button or numbered menu, text entry field, and implicit SEND key).  The
price we pay for this approach is losing application control over
presentation.  Some of that should be addressed by "layout hints" that
presentation layers can take of leave.

Other off-the-cuff advantages: easier integration with data-entry
techniques for those with disabilities, ability to work on all ranges of
platforms and display devices, clear distribution of application logic
vs. presentation logic.

I'm sure I'm not the first to have headed down this road, so any
references the group may be willing to share would be greatly
appreciated.  Feel free to tell me DotGNU is not the appropriate forum,
as well.  I think there's a thesis here somewhere though, so I hope to
continue exploring this idea.

Cheers,
-js

> -- 
> Stephen Compall
> DotGNU `Contributor' -- http://www.dotgnu.org
> 
> The GNU GPL is not Mr. Nice Guy. It says "no" to some of the things
> that people sometimes want to do.
>       -- RMS, "Copyleft: Pragmatic Idealism"
> 
> 
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers

-- 
-Jonathan P Springer <address@hidden>
------------------------------------------------------------------------------
"A standard is an arbitrary solution to a recurring problem." - Joe Hazen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]