List Info

Thread: Re: Preview Countdown Meeting -- website technologies agenda item




Re: Preview Countdown Meeting -- website technologies agenda item
user name
2007-04-06 18:23:41
Good question. We are going to move away from regular
posting
announcements to the index page on the OSAF site (and
consequently get
rid of the kludged Movable Type integration that we
currently use to
post those announcements). That site will be focused on the
non-profit
Foundation. It will have about 20 pages total (see below),
with many
of them simple archived announcements of grants, CSG
relationships,
contact information, license forms, etc. There will be
prominent
navigation aids on the index page to get the viewer to the
chandlerproject.org site.

Due to the static nature of the information on this site I
don't see
the need for anything more than simple html templates and
css.

I suppose we should figure out though if we can preserve the
existing
announcement posts and their permalinks when we discontinue
Movable
Type.

Pieter
-----------------
current OSAF website pages that will probably stay on the
osafoundation.org website
-----------------
ContributorLicenseAgreement.html	
ContributorLicenseAgreement.pdf	
CSG_Requirements_Exec_Summary_2003_05_02.htm	
donations.htm	
employment.htm	
MellonAnnouncement_Mar-31-2003.htm	
MellonAnnouncement_Sep-26-2003.htm	
mission_statement.htm	
OSAF_Corporate_FAQ.htm	
OSAF_history.htm	
OSAF_website_license_policy.htm	
PayPal_donation_cancel.htm	
PayPal_donation_thankyou.htm	
people.htm	
press_guides.htm	
SpeakerLicenseCreativeCommons.txt	
University_Requirements_Exec_Summary_2003_05_02.htm	
----------------


On 4/6/07, Matthew Eernisse <mdeosafoundation.org>
wrote:
> 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=pP90TPg
aKp_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: ht
tp://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 <eggfreeeggfree.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

> >
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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


[1]

about | contact  Other archives ( Real Estate discussion Medical topics )