RE: [chairs] Prototyping the OASIS-Open Library [w/ attachment]

["Hal Lockhart" <hlockhar@bea.com>]

Sorry for not commenting sooner, I have just now recovered from the
Symposium. ;)

The proposed design seems cumbersome from a task oriented perspective
and will involve a lot of unnecessary page flipping.

1. Most people can't upload and manage files for more than one TC/SC and
those who can (like me) usually work on a single TC at a time. Therefore
it would be best to have a link from the TC or SC page directly to ID-2
or ID-3 with the appropriate Group selected automatically.

2. I don't like ID-2 at all. I would rather go into some kind of file
display like Id-3 and have menus or buttons giving me choices of
actions. The idea that I upload files in the morning and manage files in
the afternoon is not how things work. Every page flip adds a pause of
1-5 seconds under normal circumstances. Plus I will often want to look
at existing file properties as I manage and upload.

3. On screens with a file menu like ID-3, it should be possible to
control the number of files displayed, including the option of all
files. Also either the system should always display the full contents of
a field or let you adjust field width to show as much or little of it as
the user wishes. (See the current action item display for a negative
example.)

4. Id-3 needs to be thought thru. For example, how is "Current File"
going to work when obviously you can select multiple files? What does GO
do if you fill in the filename and also fill in create directory? In
general it is a bad idea in the top three lines to mix nouns (current
directory, current file) with a verb (create directory). Also there is
another go button by "modify metadata." I am no expert in UIs, but this
seems poor.

5. It seems like it would be cleaner to combine 4a, 4b & 4c. The cases
are not that different. Designing an interface to select one file or
several is not hard. A zip could be indicated by a check box or from the
file extension. The problem with 3 screens is that they will have to be
kept in sync as metadata categories change or are added. The problem
already exists as file type only appears on 4a.

6. File type seems problematic. First of all, I assume the list will
continually get longer and need to be maintained. Second I think a pick
list would be better than radio buttons and take less real estate.
Third, other should require a text field, so we can discover when new
types need to be added.

7. Upload date should fill in automatically. Come to think of it, what
is the use case for making this user settable?

8. What is Author Name? If it is freeform text, even the same person
will not match over time. For example, I have use Hal Lockhart, Harold
Lockhart, Harold W. Lockhart and even Harold W. Lockhart, Jr. on things
I have written. If author is the account doing the updating it should be
automatic. Perhaps it would be reasonable to have a pick list of Member
Names like in the Kavi Action Item facility.

9. TC Product should be a pick list. For the TCs with one product, it
should fill automatically.

10. The current system gives you control over notifications when files
are uploaded. Are you dropping that functionality?

11. All 3 kinds of upload should bring you to the same screen with error
or success msgs. I would be in favor of standard file display, with
status msgs at the bottom, but a popup for success or failure would also
work.

12. You need to address whether multi-file and zip uploads are atomic.
Assuming they are not, you need to figure out how partial failures (of
different types) will be handled and reported.

Keep in mind that many of my suggestions for filling fields or using
pick lists are not just convenience, they will help prevent errors.

That is all I can think of right now.

Hal 

> -----Original Message-----
> From: Patrick Gannon [mailto:patrick.gannon@oasis-open.org]
> Sent: Tuesday, May 09, 2006 10:18 AM
> To: chairs@lists.oasis-open.org
> Cc: 'Greg Rundlett'
> Subject: [chairs] Prototyping the OASIS-Open Library [w/ attachment]
> 
> TC Chairs,
> 
> Please review and comment on the attached. Greg was apparently not on
the
> list to be able to post directly.
> 
> Patrick Gannon
> President & CEO
> OASIS
> 630 Boston Road
> Billerica, MA  01821
> +1.978.667.5115 x201  - office
> +1.978.761.3546       - mobile
> Skype: pgannon
> www.oasis-open.org
> 
> OASIS Symposium: The Meaning of Interoperability, 9-12 May 2006, San
> Francisco
> http://www.oasis-open.org/events/symposium_2006/
> 
> 
> -----Original Message-----
> From: Greg Rundlett [mailto:greg.rundlett@oasis-open.org]
> Sent: Friday, May 05, 2006 6:08 PM
> To: oasis-member-discuss@lists.oasis-open.org
> Cc: board@lists.oasis-open.org; tab@lists.oasis-open.org;
> chairs@lists.oasis-open.org
> Subject: [board] Prototyping the OASIS-Open Library [w/ attachment]
> 
> 
> Dear OASIS Members,
> 
> The Technology Services team and OASIS staff have been working to
produce
> a
> set of visual mockups to illustrate the proposed functionality in
> development phase one of the OASIS Open Library[1]. The OASIS Open
Library
> is being developed as the web-accessible repository for official OASIS
> standards and other TC work products.
> 
> Attached you will find a 'screen shots' document that illustrates the
> priority features of the application - namely:
> 
>    1. upload of documents to the OOLibrary (one file at a
>       time, as a zip archive, by multiple file upload)
>    2. creation of predictable URIs for uploaded resources based
>       upon path and filename elements selected by the user
>    3. creation of new folders/subdirectories in a TC's web
>       site area
>    4. automatic extraction of files from uploaded ZIP archives
>    5. designation of a URI to serve as the "latest version URI"
>       for a resource (URI aliasing)
>    6. management of uploaded files (adding/editing metadata,
>       adding annotations)
>    7. support for requesting a reserved namespace URI and
>       specifying a URI dereferenceing behavior
> 
> We are also preparing a Technical Architecture document that will be
> released shortly for your review.
> 
> OASIS staff is asking for comments on whether the functionality
described
> in
> the screen shots meets expectations and represents the desires of the
> OASIS
> membership. Please direct your feedback and discussion on the project
at
> the
> oasis-member-discuss list
> (mailto:oasis-member-discuss@lists.oasis-open.org). Note that All
OASIS
> members can send mail to that address without needing to 'join' the
group
> first.
> 
> Optionally, OASIS members may "join" (and thus subscribe to) the
> oasis-member-discuss Group/list by following the "Join Group"
> instructions at:
> http://www.oasis-open.org/apps/org/workgroup/oasis-member-discuss/ .
> 
> The public archives are visible at
> http://lists.oasis-open.org/archives/oasis-member-discuss/
> 
> [1] http://docs.oasis-open.org/
> 
> 
> Best regards,
> 
> 
> 
> 
> Greg Rundlett
> --
> Gregory S. Rundlett
> Manager
> Technology Services
> OASIS
> "Advancing E-Business Standards Since 1993"
> http://www.oasis-open.org
> (978) 667-5115 x 205
>