[Design] Preview Countdown Meeting -- website technologies agenda item

Fri Apr 6 15:52:34 PDT 2007

Just would like to confirm -- are we planning on managing 
osafoundation.org with this same system?

Are there any special issues created by the need for an ongoing 
news-posting or 'announcements' feature. Just adding new News paragraphs 
to a wiki page doesn't seem to me to be the ideal way to handle this, 
nor does manually updating a static HTML page.

The entries should probably have a title (probably used for the URL as 
well for SEO) and post-date, and be easily searchable.

Matthew

Pieter Hartsook wrote:
> After looking into this a bit more here's what I've found:
> 
>    * Almost all of our content can be managed via the wiki (looks
> like currently only 4 pages need to be static html) see:
> <http://spreadsheets.google.com/ccc?key=pP90TPgaKp_N8fH1RZVtiHg> for
> the full list.
> 
>    * for PERFORMANCE reasons the main chandlerproject.org/index page
> and the handful of pages that take a long time to serve, e.g. long
> pages of screenshot images should be served directly from apache so as
> not to hog the limited number of processes and sockets allocated to
> the wiki. This can easily be done via .htaccess so that there would
> only be one chandlerproject.org site from the user's point of view
> though it would intermix the static and wiki pages. Evidently the
> streaming media (Flash) and other files like .jpg, .ppt and .pdf
> referenced in wiki pages are in the pub directory and are streamed
> directly by Apache without going through the wiki overhead
> 
>    * by using the wiki page preference " * Set SKIN = plain"  we can
> hide all the usual wiki editing/navigation kruft for simple
> low-traffic pages, for example are statements of record that we don't
> want to imply are publicly editable, like our Mission Statement see
> this example at: http://wiki.osafoundation.org/Journal/WikiHtmlTest .
> This page is just the raw html copied from the OSAF website and pasted
> into a wiki page with minor edits to make links absolute instead of
> relative and hiding the set skin = plain statement at the bottom of
> the page by making that text color white.
> 
>    * for VISUAL context reasons we can easily adapt the new visual
> branding elements of the wiki to the static html pages of the site
> though we may want to remove the standard wiki sidebars on the index
> page for example.
> 
>    * we should manage the static pages using svn to help with launch
> updates, i.e. branch/tag Preview pages so that they can be staged and
> then pushed (or rolled back) as a unit.
> 
>   * I don't think we need any additional content management tool for
> this limited number of pages, as suggested Dreamweaver would work
> fiine for this.
> 
> Pieter
> 
> On 4/2/07, Jeremy Epstein <eggfree at eggfree.net> wrote:
>> Since I waded in earlier, I'll wade in again--
>>
>> I strongly advise using the wiki as much as possible -- its the devil
>> you know.
>>
>> Besides, I have serious doubts a  CMS  will be able to do much better
>> than the WIKI in terms of formatting-- CMSs are designed for rapid
>> updates like you would see on a news site such as CNet or a Slashdot.
>> OSAF top pages are likely not to change very much-- likely not much more
>> than once or twice a week. (that is about what mozilla seems to do) a
>> CMS is overkill for that.
>>
>> Finally if you worry about slashdotting, serve a static set of html
>> pages off of apache or lightHttpd.  Don't use any framework. Just static
>> pages. You can maintain 4 or 5 static pages with *GASP* dreamweaver or
>> homesite.
>>
>> just my .02
>>
>> Jeremy
>>
>>
>>
>>
>> Katie Capps Parlante wrote:
>> > +1 -- I agree with Ted's points here. Perhaps either *entirely* wiki,
>> > or just one "launch" page and everything else wiki.
>> >
>> > Cheers,
>> > Katie
>> >
>> > Ted Leung wrote:
>> >> I'm in favor of moving everything to the wiki.
>> >>
>> >> The problem here is not technology, it's poor human organization of
>> >> the information, which Priss/Mimi/Pieter are working to rectify based
>> >> on the Portal Project taxonomy.   If we fix that problem, I think the
>> >> wiki is more than adequate.  If we don't fix that problem, no CMS in
>> >> the world can help us.
>> >>
>> >> Ted
>> >>
>> >> On Mar 30, 2007, at 4:35 PM, Jared Rhine wrote:
>> >>
>> >>> Matthew Eernisse wrote:
>> >>>> We've talked about this before, but my vote would be to use this
>> >>>> opportunity to move the basic Web sites to an actual CMS.
>> >>>
>> >>> For some context, we think we're talking about something like less
>> >>> than 15 pages.  It's not sure yet, as we're just now doing a site
>> >>> tree so we can enumerate the separate pages.
>> >>>
>> >>>> Do we have a list of criteria to help us decide what type of
>> >>>> technology solution we want to use?
>> >>>
>> >>> My criteria, when I first raised the techn question, was "number of
>> >>> pages", "frequency of changes", and "amount of dynamism".
>> >>>
>> >>> I've two nits with our current system I'd love to improve: remove
>> >>> showing of extensions (*.php) in URLs, and use of a templating
>> >>> system which guarantees XHTML-compliant output.
>> >>>
>> >>> Also, Pieter and others are rightfully concerned about
>> >>> nav/look/function mismatch between our landing pages and the wiki.
>> >>> He's asking questions now about to what extent all of the pages in
>> >>> our landing pages could move into the wiki.
>> >>>
>> >>> There's some other crazy ideas ("replace wiki with Drupal"), but
>> >>> another criteria is we're sort of buttoned-up on our sites and
>> >>> technology in the next two months and so stable going into Preview.
>> >>>
>> >>> My view, is that we're probably looking at a small handful of static
>> >>> pages, is a lightweight Python web framework with a nice templating
>> >>> language.  Probably Pylons+Genshi or Turbogears+Genshi.  I'm waiting
>> >>> for site maps to be fleshed out before making official 
>> recommendations.
>> >>>
>> >>> -- Jared
>> >>>
>> >>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> >>>
>> >>> Open Source Applications Foundation "Design" mailing list
>> >>> http://lists.osafoundation.org/mailman/listinfo/design
>> >>
>> >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> >>
>> >> Open Source Applications Foundation "Design" mailing list
>> >> http://lists.osafoundation.org/mailman/listinfo/design
>> >
>> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> >
>> > Open Source Applications Foundation "Design" mailing list
>> > http://lists.osafoundation.org/mailman/listinfo/design
>> >
>> >
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
> 