On Sat, 5 Aug 2000, earth wrote:
> 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.
It's the BigDeal Part I. The BigDeal Part II is the integrated editing
tool, which is much farther down the line, unfortunately.
> 1) Requires API from XMLDatabase and BackLinkDatabase
> 2) Output is HTML perhaps with javascript.
One of the up-front requirements is that the viewing engine will support
all kinds of output, although the system that we build will initially
support HTML w/ JavaScript (or as Joe says, XHTML with ECMAScript).
This is an important, up-front design requirement. The viewing engine
does have to be extensible in this way. The solution that Doug seems to
like is IBM's WBI. WBI is not open source right now, and as I mentioned
on Thursday, I'm concerned that it may be difficult to convince IBM to
make it so, although Doug disagrees with me on this. It would be helpful
if someone took a look at it and did a good evaluation on how well it fits
our needs. If it is indeed the best tool for our job, then we need to
start negotiating with Jim Spohrer about making it open source so that we
can use it.
> 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?
I think it's fine for our initial system to use JavaScript, although we
should make sure it works in IE and Netscape. And because our viewing
engine will easily deal with any type of output, Lynx lovers like myself
will be able to easily write their own views for the system.
> 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 ?
XHTML, which should work with existing browsers for the most part. My
thinking on stylesheets is that we should support XSLT on the server side
-- in other words, for now, let the viewing engine deal with styles rather
than rely on the clients. Getting CSS to work on both IE and Netscape can
be a real pain, especially if you're trying to do funky things. However,
I wouldn't be opposed to using CSS in our system if it helps us do what we
want to do.
> 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?
Very good question. From previous discussions, people seem to like a
servlets/JSP solution, and I think there are strong arguments for doing it
this way. However, I also believe strongly that the initial rev of what
we write should be thrown away fairly quickly, which would bode well for a
Perl/mod_perl or Python/Zope-based solution. Doing it this way would
allow us to develop things quickly, and would give us the option either to
stick with a particular language or to move to a different system
entirely. Heck, maybe we'll decide that C++ is the best language for our
needs at that point. Doubt it, but maybe.
> 4) Document Core Functionality. Is there a specification for the
> core functionality of the interface to this piece of OHS
> for this version?
I've got some initial stuff that we worked out at previous meetings. I
promise, I'll get them up on the web before the weekend is over.
> 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 (?):
We don't have anything worked out at the level of 4a-4c; that's something
that needs to be done. I have some thoughts on these that I'll share
when we reach that point.
> 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.
We've worked out some initial views, which I'm also due to post. Within
the next two days, I promise.
> 6) User authentication system? Does the V1 of this need to be
> user-aware and able to accept or reject viewing by authentication?
Very good question. Perhaps not for V1, but very soon after that; we'll
need it to support the Reply-From-Browser feature. We should probably
build it in from the ground up, because we will definitely need it, and
we'll be able to do some cool views with it, such as maintaining a
personal "e-mails read" database for each user, similar to .newsrc files.
> 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.
Nope. Getting as much Augment stuff as possible available is definitely
on our To-Do list. Shinya and Grant are working with Doug on pieces of
this, and Joe has made some very good suggestions regarding this as well.
> 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
Hasn't been worked out. Propose something.
> 8) Consistent Navigation. Header / Sidebar + footer consistently
> present navigation bars. What should exist on every page?
> Should there be context/depth based navigation bars?
Hasn't been worked out. Propose something.
> 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.
Agreed.
> 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?
As I mentioned earlier, keeping track of e-mails viewed.
-Eugene
-- +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+ | "Writer's block is a fancy term made up by whiners so they | +===== can have an excuse to drink alcohol." --Steve Martin ===========+
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:49 PDT