|[Date Prev] [Date Next] [Thread Prev] [Thread Next]||Indexes: Main | Date | Thread | Author|
Gary, (01) 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.... (02) http://www.welchco.com/03/00050/61/02/07/3001.HTM#BM5N (03) ...along with Jack, who raised the idea on 000518, also noticed in the letter on 020730.... (04) http://www.welchco.com/03/00050/61/02/07/3001.HTM#9F9G (05) Rod (06)
--- Begin Message ---
- To: Rod Welch <email@example.com>
- From: "Garold (Gary) L. Johnson" <firstname.lastname@example.org>
- Date: Mon, 12 Aug 2002 13:26:24 -0700
- Message-id: <MIEJJJFBHJEBDEKGPHOPMENLCPAA.email@example.com>
--- End Message ---
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....
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.
Garold (Gary) L. Johnson