The key aspect of my task 6 is that multiple archives are created based
on the "Subject" lines in the messages. The filtering step routes
different messages to different archives based on the subject. One
step that needs to be made explicit is that the user reviews a list of
subjects and decides into which archive a message with a particular
subject goes. This mapping of subject to archive will need to be made
persistent. That means the mapping must be able to be created,
reported, updated, and deleted.
The multiple archives get located to different places, possibly on the
same systems where the mailboxes came from, or possibly not.
> Task 7:
>
> User: From task 6.
>
> Task: User has been archiving mail from multiple email accounts locally.
> Student will convert multiple archives to html. The html pages will be
> organized by subject (Blond Jokes, Polish Jokes, Story Jokes, Lewd Jokes,
> etc.). Then html needs to be transfered to remote server, to be made
> available to public. When files are transfered to remote server, they
> must be placed in seperate directories because the student wants to
> maintain control over the web site.
The key difference in task 7 is that the user can examine the list of
subjects and specify multiple subjects that can be treated as one subject.
For example, if you look at the Phase 2 page, the subjects "Task Scenarios,"
"tasks and scenarios," and "Tasks" should all be treated as the same subject.
In task 7 the user needs to review the list of subjects and determine which
ones should be treated as the same subject.
> Task 10:
>
> User: From task 6.
>
> Task: User has done task 6. He receives another joke email from a
> friend. He takes the email from the remote site, and brings it local.
> Then he converts it to its own html file. Next it is transferred to the
> remote server that has the web pages already in existance, and is added
> to the existing html formatted archives, based on its subject.
>
I think task 10 is one of those optimization steps that would not be visible
to the user if it were implemented. It requires more bookkeeping by the
application. Note that the way the messages and articles are indexed,
there would be new page for the new message, plus all of the indexes (currently
there are four of them) would need to be replaced. It might show up at
the user interface if we reported progress in great detail. Otherwise
I don't think it is a user interface detail.
Note that here is a link to the hypermail documentation at the bottom of
each of the generated index pages. You should all take a look at it when
you have a chance. (For that matter, I'm not sure we are firm on using
hypermail yet, but it is still a workable starting place.)
> Please take a look at what I have written here. Is this what the task
> should look like? I only wrote out tasks 6, and 7. 10 I added because I
> think it is a task that we should list. Actually, I am the student that
> is being listed as the user, and this is a task that I would do.
>
> Please check to make sure that I have done the tasks right...That means
> that this isn't specific instructions on how to use our system, or any
> other system. Is it detailed enough? Too detailed? Not representative
> of a task our user might do?
The task definitions look pretty good; more detail than what I outlined
was what I was hoping for.
> Please give me some feedback. I should be on my computer most of the
> afternoon, and should be able to return email messages in a matter of
> minutes.
>
> Thanks,
> Jeff
>
> ryex0006@gold.tc.umn.edu
> ryex0006@itlabs.umn.edu
> jrye@pigchamp.caps.umn.edu
>
>
Jeff, you missed out on our meeting yesterday. Some details about that
meeting that Quang left out. The system can be viewed as a four-step
process.
1) Gather.
2) Filter.
3) Converter.
4) Scatter.
Eventually we would use a metaphor of a project. A project contains
the information about what mailboxes are to be gathered (including the
information about hosts, directories, user IDs, and passwords), how to
filter the messages (including using subject, date, and other criteria
to determine which "notebook" a message should be filed into), and where
to scatter the "notebooks" when the converter is done with them (including
information about hosts, directories, user IDs, and passwords).
The "project" notion is one borrowed from Hot Dog Pro, an HTML editor from
Sausage Software, but probably used by others. With a project as a
persistent object, if you wanted to update your pages, you just load your
project and have it go. If your project description was complete, everything
about the four processing steps would already be known; you wouldn't
have to respecify anything.
dsc