[cdwg] OpenSFS web site requirements

Christopher J. Morrone morrone2 at llnl.gov
Fri Aug 3 17:37:30 PDT 2012


I don't understand this comment:

"We have attempted to integrate the wiki 
http://wiki.lustre.org/index.php/Main_Page into our website. We have not 
been able to make the wiki work."

What exactly did we try?  Did Oracle give us the source for that?  The 
top level of that is terribly out of date anyway.  But there is content 
under there that we could likely copy (where legal to do so).

But I'd drop that statement altogether.  What we tried in the past isn't 
particularly useful to a web designer.  Instead we need to focus on 
telling the web designer what we want.

Here's another thing we should drop:

"Wiki – attempted to integrate MediaWiki; it was too cumbersome and 
difficult to use
and explain to our working group leads. We need something with a easy 
interface like
wikipedia"

Not sure why they would need to know that.  The we can choose any wiki 
we want and set it up independently of the more static web pages.

I think what we want are really two sets of web pages, with somewhat 
different styles.

1) OpenSFS (opensfs.org, www.opensfs.org)
2) Lustre (lustre.opensfs.org)

OpenSFS's pages should be all about the organization, what it does, who 
its members are, lists of activities, etc.

The Lustre pages on the other hand should not have "OpenSFS" branding 
across the top of the page; they should say "Lustre".  The OpenSFS 
sponsorship should be noted, but more subtly along the bottom.  E.G. 
"brought to you by OpenSFS".  The Lustre pages need to focus on Lustre: 
what it is, how to get it, where to go for help, where to go to get 
involved in development.

This comment looks bad to me too:

"Platform/software; currently using Wordpress. We need to be able to 
edit with WYSIWYG editor."

I think that we would either have a CMS, where content can be edited 
through the web, or use more static pages that are styled through CSS, 
and you can edit the html page in any text editor.  Requiring that the 
entire page be edited through a WYSIWYG editor probably contrains 
designers to using proprietary and expensive tools, which will make 
maintenance more obscure and difficult for those of us involved with 
changing information on the web pages in the future.

I think we probably need to keep our "requirements" more high level like 
this when we start the contract.  It looks like the current pdf takes 
more of a brain-dump approach to listing every possible thing we'd want 
to mention in the web pages.  I would question whether the entire table 
labeled "Audience" should appear in the document at all.

I imagine that a good web designer will ASK us what the content should 
be and how it needs to be organized, and we would iterate on the look, 
content, and organization with the developer many times.  For intance, 
it is to early to call out details like "we need a link to our revision 
control system" or "we need a link to our issue tracker".  That is just 
content.

The things we should probably consider and state are:

1) Do we want a CMS?  Or do we just more-or-less static web pages + CSS?
2) Should we state that the pages must be generated by, hosted on, and 
editable from Open Source tools?
3) Should state that the pages must render reasonably well in a variety 
of browsers (Firefox, Safari, IE, just as examples), and perhaps make 
correct rendering in a specific set (including version number) part of 
the requirement.
4) "Search engine optimization".  Should include reasonable meta data 
and organization so that search engines can properly index the pages.

I like the "Structure" section.  But I would argue, as I did earlier, 
that weed need two portals: one for OpenSFS, and one for Lustre.

Under "Capability/features", there are some things that I don't 
understand.  Do we really need our own calendaring solution, or do we 
just need a links to google calendars?  If it is just links then it is 
content, and not a capability/feature.  I would say the same for wiki 
and forum.  I don't see a need for complicated functionality here. 
Solutions already exist that work well, we just need links to them.  So 
then these things are just content, not capability/features.

Under "Capbility/features" it says "Scroll bar".  What is that???

Commerce: really???  A system for processing money built-in to the site 
is going to be a great expense for something that we use infrequently 
(LUG).  Can't we handle that through existing services external to the 
opensfs site?

Ah, in the "AVAILABLE TECHNOLOGY RESOURCES/INTEGRATION ISSUES", it gives 
a clue that WYSIWYG is just being used incorrectly.  We don't want 
WYSIWYG really, just interface that normal folks can use.  "Content 
editing through web pages" (implying a CMS) might be a better phrase.

Thats all for now,

Chris

On 08/03/2012 01:53 PM, Hamilton, Pam wrote:
> Hi all,
>
> OpenSFS is in the process of drafting an RFP for getting the OpenSFS web site revamped. I've been directed by the execs to gather requirements from the CDWG for the web site. There is a draft RFP on the OpenSFS home page which does try to capture some requirements (http://www.opensfs.org/wp-content/uploads/2011/03/opensfs.org-RFP_sss5.pdf).
>
> Some information in the RFP is dated since OpenSFS now has a functional wiki at http://www.opensfs.org/foswiki/bin/view/Main/WebHome. I have not had time to add any CDWG content yet but hope to start soon. I recommend checking out the wiki's functionality and sending in any feedback you may have.
>
> Here is the start of a list of web site requirements to get us thinking about what we need/want:
>
> * When one "googles" Lustre, the OpenSFS web site should be at the top of the list or close to it
> * Emulate linuxfoundation.org especially with regard to how working groups are handled
> * Working group pages should be managed by the working group leads and facilitate accessing the OpenSFS wiki
>
> Web site requirements will be the topic of our next conference call but please feel free to respond to this email with your ideas. Stay tuned for the announcement of our next conference call.
>
> Regards,
> Pam
> ___________________________________
> Pam Hamilton
> Lawrence Livermore National Lab
> P.O. Box 808, L-556
> Livermore, CA  94551-9900
> E-Mail:  pgh at llnl.gov
> Phone:  925-423-1332          Fax:  925-423-8719
>
>
> _______________________________________________
> cdwg mailing list
> cdwg at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org
>





More information about the cdwg mailing list