[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

[ba-ohs-talk] Re: SDS and 3-layer architecture

Interesting observation. It makes sense.    (01)

What SDS needs is some kind of communications wrapper that
lets you use the linked infor to create something readable with it.    (02)

I'm not sure where you stand in your development efforts, or
what time you have to commit to the project these days, but that
would seem to be the next frontier for development.    (03)

The result would be a raft of people who are immediately impressed
by what they see, and who are then likely to want that technology
that produced it.    (04)

I learned that lesson the hard way, after developing a little expert
system and demonstrating at the company's trade show as "cool
technology". The show was oriented to the 99% of the world who
want to be users, rather than hackers, and they could care less
about the technology. They wanted to know what the program
*did*. Since it didn't do much of anything useful, they quickly lost
interest and walked away.    (05)

At 40 or 50 people interactions a day, it was an extraordinarily
valuable lesson in the importance of showing people something
they *want*.    (06)

Rod Welch wrote:    (07)

> Gary,
> Your letter today raises important questions on managing a DKR which
> the OHS/DKR team may be ready to take up.  The letter on 020730
> suggested that Eric might look at the architecture issue....
> http://www.welchco.com/03/00050/61/02/07/3001.HTM#BM5N
> ..along with Jack, who raised the idea on 000518, also noticed in the
> letter on 020730....
> http://www.welchco.com/03/00050/61/02/07/3001.HTM#9F9G
> Rod
>    ----------------------------------------------------------------
> Subject: SDS and 3-layer architecture
> Date: Mon, 12 Aug 2002 13:26:24 -0700
> From: "Garold (Gary) L. Johnson" <dynalt@dynalt.com>
> To: Rod Welch <rowelch@attglobal.net>
> Rod,
> You asked for comments:
> > On a related matter, looking forward to developments of your idea
> for
> > a document format that enables people to use the SDS record without
> > all of the links.Have you discussed this with Jack in connection
> > with his plan for a 3-layer architecture....
> http://www.welchco.com/03/00050/61/02/07/3001.HTM#9F9G
> This letter is a good example of what I was aiming at. The letter can
> be read and understood from start to finish without having to follow
> any links at all. The links then provide access to supporting
> information and additional details. This means that there are no side
> tracks involved in reading and comprehending the communication, but
> access to supporting details is available when it comes time for
> deliberative analysis.
> I think that it is important to note the difference in intended use
> between SDS records and documents to communicate to management. This
> also speaks to the role of a Com Officer. SDS records need to be
> understandable in themselves, but they are designed to be used during
> the process of deliberation rather than for communicating a new
> concept. I think that Eric is reacting to being dumped into the middle
> of a record intended for use by a Com Officer and expecting to se a
> document intended for standalone communication. When you produce
> communication documents as the letter referenced above, they are quite
> different from the entries in SDS records, and that is as it should
> be.
> Note also, that SDS supplies records in context and chronologies, so
> that this doesn’t have to be done manually. While browsing SDS records
> from a single entry, that context is missing. The result is that there
> can be numerous links to follow in order to establish the full
> context. The organization of that context can be difficult since we
> browsers provide no support at all for retaining the relationships
> between viewed pages. The result is that the browser user has many
> pages open simultaneously with no way to organize them even
> temporarily. It is easy to get lost in all the windows. Consider what
> your hard drive might look like if you had only individual files with
> links to other files and no access to the directory structure – there
> would be no visible organization and no easy way to know that there
> were other relevant pages available. This is exactly where people
> accessing the SDS record with a browser find themselves – they do not
> have access to the organic subject structure or to chronologies, and
> the entire thing appears to be a mass of links in which they quickly
> get lost trying to keep the relationships in their heads instead of in
> accessible lists or structures.
> Since perception depends heavily on context, people viewing SDS
> records without the context provided by SDS can react as Eric did,
> that there are “too many links”.
> This is not intended to indicate that there is any defect in the SDS
> record when used with SDS, since it clearly works as needed there.
> This is what I meant when I talked about creating a CD-ROM that worked
> with a browser in a way similar to the way a user would experience
> SDS. This would require various pages or indexes to simulate the
> various contexts available to the SDS user.
> I don’t think that Eric, Jack, and others who have complained about
> SDS understand the distinctions among
>    * SDS records intended for use in an SDS context
>    * Documents intended for communication to executives
>    * Contexts available within SDS that are not available from a
>      browser.
> I haven’t discussed Jack’s 3-layer architecture with him, nor its
> relevance to further development of SDS. I will look at his letters
> again and see if there is anything to add to this.
> As far as “a document format that enables people to use the SDS record
> without
> all of the links”,I haven’t done anything more with that. I am not so
> much trying to produce a new SDS format as I am trying to find ways of
> providing some of the benefits of SDS with current tools in the hope
> that people can see and understand that the functions are valuable.
> Since there are so few examples of well linked records, I am still
> looking at ways of producing one.
> Thanks,
> Garold (Gary) L. Johnson
>    (08)