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 <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
