/990111
Following is a preliminary attempt at specifying the
JabberwockyProject.
(Please insert/append comments, and/or to IaRad, iaJava@yahoo.com .)
Preliminary Requirements
Introduction
WikiWikiWeb is an impressive collaboration tool. It is being put to use
in commercial IntraNets as well as FreeWare projects. But it has its
limitations. The JabberwockyProject intends to supplant and reach
beyond Wiki, by building on a far stronger foundation: Java, Servlets,
and Applets. (Also JabberwockySuggestion.)
Purpose
Wiki is a Web-based collaboration tool, implemented by CGI scripts,
a DB of text streams, and HTML FORMs and rendering on the client side.
To better supports the needs of FreeWare projects groups, we would want to integrate Wiki with some revision control
system, or enhance it with appropriate features.
Many aspects of group work call for automation/scripting of tasks, like: Notification (by eMail), members directory, resources (bibl/URLs) collections, recent changes, indexing and search, bug tracking, decision/resolution support, etc [MAN94].
Administration of the project's Hypertext must also be remote: Including access control (ACL) management, uploading new scripts/servlet-components, etc.
Essentially, a foundation should be built, to enable many applications: Workflow management, teamwork software development, discussion eForums (newsgroups/boards), computer-based training, publishing, Web indices, ...
This tool/system will appeal to commercial IntraNets, as well as virtual communities, like our own (JOS, here).
What do you think?!
Suggested taxonomy (categories) for requirements
elicitation and specification:
- Storage
- User Interface
- Administration Tools
- HyperText/HyperMedia
- Metaphores/Architecture (For intended uses/applications)
- Security (Privacy, authentication, integrity, etc)
- Integration with Other Tools
Methodology
Suggestions?
I'd prefer a formal, consistent approach [POT94].
Let's start designing (an architecture) and see if we need
to broaden our view, and systematize this.
-- IaRad
Storage
Synopsis: In Wiki, the Hypertext consists of flat plain text nodes
that map to HTML pages. Each page has an identifier (key):
its WikiName.
Important features of Wiki node identifiers?
- Identifiers being WikiName s makes it easy to link to any node
- Note the assumption that WikiName s are readable (resemble English phrases) and easy to remember, otherwise you couldn't link to or search for them [1]
- There's a single scope ("name space"), so you can't have two nodes with the same identifier [2]
- WikiName convention might make links of plain text where not intended (acronyms, crackers' typo...) [3]
Features of Wiki nodes?
- Nodes have no structure, no attribute=values associated, so cannot be automatically processed
- Nodes are ASCII text (or ISO 9958-* ?)
Notes
- Well, must identifiers be readable? Always? Note adoption of "naming conventions" and rising length of _identifiers_. Yes, HTML guidelines mandate highlighting a pharse from the text, not inserting an explicit "click here"
- How does this limit the Hypertext? Yes, you can explicitly link to other "web" in Wiki, by hand
- What if we wanted to replace/update all links to some page? I'd prefer explicit markup for links over WikiName s
User Interface
Synopsis: Wiki is a plain text Hypertext, where each node
is directly mapped to an HTML page sent to a browser.
What about Multimedia? We want JabberwockyProject to support
Webs for FreeWare development, and then more complex
collaboration applications, for IntraNets.
Issues?
- Viewing (UI, interactive, etc)
- Overview (summary, table of contents, threads, etc)
- Editing (tagging, linking, etc)
- Handle simultaneous editing, obvisouly
- Spell checking option
- Access control (see Security)
- Backwards compatibility (support Wiki tags)
Suggestions?
- Node composition: Granularity -- can't nodes be sub-pages? (Think of, eg, WebBoard tools, SSI, ...)
- Direct editing: Browser could support editing of page, instead of <FORM> with text box, and updating node from there (We are writing in Java, right?!)
- Why not, then, support binary nodes? Applets? Uploading/downloading ZIP and source code? Uh?!
Administration Tools
?
(See also discussion in ClassRepository)
HyperText/HyperMedia
Suggestions?
- Ensure all nodes are linked
- Support for GIF files
- Support for JPEG files
- Support for AU files
- Support for WAV files
CayteLindner
Metaphores/Architecture
?
Security
Suggestions?
- Privacy -- hide personal eMail addr? This will protect against spam?
(See also discussion in ClassRepository)
Integration with Other Tools
?
- Support for commercially available plug-ins
- Support for forms
- Support for JAVA applets
CayteLindner
Also see:
Bibl/references:
- M Mandviwalla + L Olfman, "What do groups need? A proposed set of generic groupware requirements", ACM tran CHI v1n3 Sep94 p245-268
- C Potts + K Takahashi + A I Anton, "Inquire-based requirements analysis", IEEE Software Mar94
I'd like to see projects and their associated tasks represented as trees, with the subtrees being the subtasks. A user with very little time could sign up for a leaf. A user with more available time could sign up for a subbranch and later, maybe delegate subtrees. The idea is to provide opportunity at every level of commitment.
CayteLindner
|
Content of these pages are owned and copyrighted by the poster.
|
|
Hosted by:
|
|