Re: Extending Gnome Storage
- From: Seth Nickell <seth gnome org>
- To: Ayo Forde <fordea0 cs man ac uk>
- Cc: storage-list gnome org
- Subject: Re: Extending Gnome Storage
- Date: 07 Oct 2003 16:59:23 -0700
Hi Ayo, I've forwarded your message on to storage-list gnome org If you
want, you can subscribe at
http://lists.gnome.org/mailman/listinfo/storage-list.
> I'm currently in my final year at the University of Manchester. For
> my final year project I would like to extend Gnome Storage so that
> users of different interests can retrieve information that is relevant
> to them. For example there are technical writers, testers,
> developers, managers, people who work in service and sales, who might
> be interested in files about a new product. However, the files
> required will be quite different. Example developers might be
> interested in the actual code of the product; while persons in service
> are only interested in manuals on how the product should be used, and
> troubleshooting guides; persons in sales only care about the benefits
> of the new product, hence they are only interested in charts on
> predictions on success of product. The project aims to solve this
> problem by allowing persons of different backgrounds and interests to
> only retrieve files relevant to them.
The first goal in anything related to Storage is to think about how it
effects the design. I do not have a clear idea what sort of interface
you are thinking about for this sort of functionality? How do you see it
operating in a "real world" use context? The basic idea of integrating
"projects" into the core of Storage I have considered, and I think this
could be a very useful refinement of that concept, but we probably
should hone the design more closely before worrying about the technical
implementation. Doing the actual attribute tagging for each "role"'s
relation to the file is extremely easy.
So the steps I would see for this sort of extension of Storage would
look something like this:
1) Collect information on how target users currently interact, how
projects inside *real* companies work, etc. (this sort of stuff was done
by me for all the existing Storage components... it can be a PITA but
even a couple days of work on this can give you a much better idea of
real problems than just guessing how different job roles interact)
2) Get a rough idea of how the interface should work to address problems
that you have observed in researching how people work. This could
definitely include some idea of different job roles and relevance, but
build the information off (1), not *just* what your creative ideas are.
3) Figure out a set of technical requirements from that for the idea of
"Projects" inside Storage
4) Design an API for Projects in Storage
5) Implement :-)
As for the Storage code, you can find it in GNOME cvs under the
"storage" module. Right now NL is a mess, but libstorage and the store
itself should be working fine.
-Seth
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]