For example, messages posted by Joseph Dal Molin and me pertaining to
the upcoming VistA Community Meeting in Pittsburgh
(http://www.worldvista.org/Event_Calendar), the VistA Community Call on
Friday, May 12, and other topics have not made it to my mailbox or to
the mailing list archives. I don't know whether some members have
received these posts and others have not. Yet at the same time, some
posts are getting through. As near as I can tell, replies to threads
started more than a week ago are making it through, but this may be
nothing more than circumstantial evidence, like the lucky rabbit's foot
that one might carry in ones pocket before going out to hit the big one
at the ball park. Be that as it may, I am posting this message as a
reply to an older thread in the hope that it will get through, and the
list moderators can take it up with Source Forge.
A couple of years ago, some of us played with Google groups to evaluate
an alternative to the current hardhats list. Google appears to have
improved it since then. In particular, although you need a web based
interface to post, you shouldn't need web access to read because it has
RSS and atom feeds. Go to http://groups.google.com/group/vista to
access the VistA Google group. Let's use it for now.
I am copying the openhealth list because there is an overlap of members,
and also two who I believe are moderators of the hardhats list.
-- Bhaskar
On Sat, 2006-05-13 at 17:45 -0500, Gregory Woodhouse wrote:
>
>
> One of the hazards of being a developer is that it is all to easy to
> look at matters such as the structure of a user interface from an
> implementation perspective. An example of this is that when graphical
> user interfaces are identified as an addition to traditional VistA
> that has the potential to increase the acceptance of VistA, discussion
> immediately turns to such matters as
>
>
> 1. How do we get it to work with a mouse?
> 2. How can we display content in a window?
> 3. How can the Kernel menu system be integrated with a GUI?
>
>
> But these questions fundamentally miss the point. Think about a
> traditional roll and scroll interface: it reflects the sequence of
> updates to individual field in the record currently selected. In other
> words, it directly mirrors the implementation, and is not focused on
> the needs or goals of the user at all. The fact that it uses a
> terminal window is really incidental, and it distracts from the more
> fundamental problem building an interface around the user and his or
> her needs, rather than building an interface that is convenient to
> implement (or even one that seems natural or intuitive to the
> developer). Another trap is identifying a style of interface with a
> particular element of that interface. When we hear that a user wants a
> graphical interface, then we think: Ah, the user want to be able to
> use the mouse. Or perhaps: Ah, the user wants data displayed in
> formatted windows. Again, this misses the point. Of course, graphical
> user interfaces and text based user interfaces exhibit a considerable
> amount of variability, but there are patterns. For example, a
> graphical user interface may display on screen objects ("nouns" if you
> will), but the classical roll and scroll interface allows you to
> select an object once (in a Fileman lookup) and the subsequently you
> are invited to modify, or otherwise act upon, that object. In other
> words, the interface elements are verbs or modifiers, and you are
> asked to remember what the noun is. To take a typical example from
> graphical user interfaces, drag and drop, the situation is exactly
> reversed: the nouns are explicitly displayed on screen, but the verb
> (say, copying a file) is implicit in the action.
>
>
> I am not suggesting that one is right and the other is wrong, only
> that the reason that users may prefer one type of interface over the
> other typically run deeper than the presentation modality. We ignore
> the user's concerns at our own peril.
>
> Gregory Woodhouse
> [EMAIL PROTECTED]
>
>
> Metaphors be with you.
>
>
>
YAHOO! GROUPS LINKS
- Visit your group "openhealth" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
