available in wiki at:
http://www.bootstrap.org:8080/OHS/ViewerEngine
Here's another attempt at getting some conversation started about
whats involved in getting from here to there.
Viewer Engine for OHS Email Gateway V1
This seems like too big chunk to me to try to attack so here's
a quick attempt to break it up a little with lots of questions.
The "ViewerEngine" seems to me to be the BigDeal, in that it
is the primary non-email interface to the system which gives
users access to all the cool extended functionality of OHS.
This is an ugly mix of design, tech, and requirements.
1) Requires API from XMLDatabase and BackLinkDatabase
2) Output is HTML perhaps with javascript.
Question: Some people object to javascript for general audience
tools because its support is spotty outside windows and mac.
How do people feel about JS?
Question: What spec HTML is the target? HTML 4 with style
sheets and the like? Assume mozilla and msie 5 or should be
be fully compatible with NS4 ?
3) Weight of Engine: is this intended to be installed easily
on most systems (written in perl or 'stand alone' scripting
language), or is it reasonable to require PHP or require
zope or some other module or engine? Do we have an initial
customer target list that we can query and find out what they
would want or what they are willing to install for the sake
of this product?
4) Document Core Functionality. Is there a specification for the
core functionality of the interface to this piece of OHS
for this version?
Would this be in the augment docs or as part of one of the
pieces of earlier emails? It would be great to get the basic
list on a URL somewhere. It would probably include stuff like (?):
4a) Paragraph Anchors. Each document displayed is paragraph
addressable using HTML anchor tags (<A NAME>). Each paragraph
also has the paragraph number or ID displayed clearly next to
the paragraph itself in a system-specifiable style (color, font,
size?).
4b) Backlinks: Design for backlink display. Perhaps either
a link on each page goes to a page showing all the backlinks
for the current document or a standardized thing in the footer
showing some information about backlinks .. or?
4c) more.. what?
5) Indexes. Document/Message indexes including: show organized by
topic, by date, by author, by number of backlinks?, ??. By Topic organization would probably be similar to HyperMail / webforum style.
6) User authentication system? Does the V1 of this need to be
user-aware and able to accept or reject viewing by authentication?
Interface Design Stuff:
Are there screen shots of Augment ? I failed to find augment
on bootstrap after a brief search. It seems key to get
some folks together to do some interface sketching.
7) Front page. Human-easy entry page. What does the front page
to the basic system want to look like? What elements of the design
of the interface
8) Consistent Navigation. Header / Sidebar + footer consistently
present navigation bars. What should exist on every page?
Should there be context/depth based navigation bars?
9) Pluggable Look & Feel / Navigation. The more potential users and
the larger the potential users the more it seems likely that
this system would need to support pluggable headers and
footers of at least some basic kind to allow big groups and
corps to clearly integrate the system into theirs.
10) Search. This depends on the XMLDatabase portion of the system.
I am personally a huge fan of JumpTo or hash-based most common
searches systems sitting on top of search engines or database
queries.
11) User Settings / Preferences. Cookies can work well for per-user
settings / preferences. What preferences might users have
when working in this system? Would colors all be standardized
to have global/syntactic meaning or would colors fall in user
settable preferences area?
12) losing steam, time to quit for now :) did I mention that wiki is
insane? its auto-renumbering reminds me of working with MSWord.
b
earth
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:48 PDT