Make your own free website on

IRC Log 2001-08-26 #web

approximately 20:00 GMT - 22:30 GMT

You're best off using a good CSS-enabled browser. (Like Mozilla ;) It's easier to read that way.

<hwaara> Gerv, what's first on the agenda of yours.
<jmkg> well we don't want scraps of information and lists posted to the mailing list
<jmkg> so we want them in one repository which is maintained
<Gerv> OK.
<Gerv> There are a few simple ones to begin with:
<Gerv> 1) Content types. This is a zope thing - it's kinda like you need one for each sort of doc you serve.
<Gerv> There are some default ones,
<Gerv> and we'll need XULDocument and XMLDocument as well.
<Gerv> If, when thinking, we note that there's another content-type we use
<Gerv> (e.g. SVGDocument)
<Gerv> then we need to keep a list.
<Gerv> That's a simple one.
<Gerv> But people need to be aware.
<Gerv> 2) workflows
<Gerv> We need to have the discussion about exactly what review we have, if any, and what that involves.
<Gerv> Who needs review and who doesn't,
<Gerv> and so on.
<Gerv> This is what Zope calls "workflows",.
<Gerv> There is one default workflow,
<Gerv> which I think may well do the trick, at least to begin with.
<Gerv> It works as follows (thanks to pw):
<Gerv> a. User (e.g. Member) with a low-privilege role creates a piece of
<Gerv> content.
<Gerv> b. Member then requests that the content get published.
<Gerv> c. The "Reviewers" then receive a message saying they need to approve
<Gerv> something.
<Gerv> d. The Contributor role is allowed to author content that doesn't need
<Gerv> review.
<Gerv> There are other themes and permutations here, this is just one
<Gerv> workflow. Also, note that in the PTK, any item can be "discussable",
<Gerv> that is, everything can have a threaded discussion embedded into it.
<hwaara> I'd say, start with the architectural and structural issues and then discuss the technical details (such as content types).
<Gerv> There are four "roles": User, Member, Contributor and Reviewer.
<Gerv> Sorry, that's wrong.
<Gerv> Strike User from that list, and add Manager.
<Gerv> hwaara: I'm working down a list.
<Gerv> Does it matter what order it's in?
<Gerv> Anyway, we need to decide if that workflow will work for us.
<jmkg> uh
* Fabian likes it
<Gerv> 3) IP. We need to work out how IP rights are going to work.
<jmkg> mind listing those roles again?
<jmkg> i.e. correctly
<Gerv> Member, Contributor, Reviewer and Manager.
<Gerv> See above for the distinction.
<jmkg> thank you
<Gerv> No problem.
<Gerv> We need to decide if we have a uniform license.
<Gerv> If so, how does that work with old content.
<Gerv> Do we ask everyone with posting privs to sign something?
<Gerv> Do we just state that "if you upload it, it's OpenContented"
<Gerv> or whatever license we choose.
<Gerv> Etc. etc.
<Gerv> 4) Skins.
<Gerv> We need to choose a few people to learn the skins tool and do skins.
<Gerv> We can then have a look and decide what we like and what we don't.
<fantasai> What are skins--just presentation?
<Gerv> I should note at this point that staff"
<hwaara> Can we please take one thing at a time?
<Gerv> reserve the right to make a final decision on this one.
<Gerv> hwaara: This is a _list_.
<Gerv> We are _not_ discussing these points.
<Gerv> We are making sure we know what to discuss.
<hwaara> The list obviously includes lots of subcontent. ;)
<Gerv> I'm sure other people have things too,.
<Gerv> I just happen to be going first :-)
<hwaara> ok.
<jmkg> fantasai: skins are the presentaional look (the html and css and graphics) to the webpage
<Gerv> Skins: we need some skin guidelines to give people an idea of what we obviously don't like.
<Gerv> For example, tables for layout _might_ or _might not_ be in such a list.
<Gerv> 5) Migration.
* Fabian grumbles at the sound of tables
<Gerv> As we go, we need to put together a migration howto for people moving content.
<Gerv> This might include e.g. "use HTML Tidy"
<Gerv> or "fill in all the metadata fields"
<Gerv> or "use the styles from our default style sheet if you like".
<Gerv> Basically, people should be able to read it and know how to turn an HTML file on their drive
<Gerv> into a piece of hosted content.
<Gerv> 6) URI structyre,
<Gerv> Enough said.
<Gerv> But we also need to decide _how_ the final decisions will be taken before we even start thinking.
<Gerv> Otherwise this could go on for ages.
<jmkg> indeed.
<Gerv> 7) Metadata.
<Gerv> We need to decide what we need, work out how to get Zope to accept it.
<Gerv> What's compulsory, what's optional.
<Gerv> 8) Content standards.
<Gerv> Which version of HTML, a default style sheet, tags we don't allow, structures we frown on (Tables ;-)
<Gerv> Level of grammar and spelling.
<Gerv> Etc
<Gerv> .
* Fabian dreams of coconut trees and sandy beaches and women
<Gerv> OK, that's my list :-)
<fantasai> nice list
<jmkg> ok
<Gerv> I'll re-bullet it:
<Gerv> 1) content types
<Gerv> 2) workflow/roles
<Gerv> 3) IP
<Gerv> 4) skins and skin howto
<Gerv> 5) migration howto
<Gerv> 6) URI structure
<Gerv> 7) Metadata
<Gerv> 8) Content standards
<jmkg> I suggest we sort out the decision making one first.
* Gerv wipes his brow.
<Gerv> Whoa a sec.
<hwaara> Agreed.
<Gerv> Does anyone else have stuff to add to that list>?
<jmkg> well
<jmkg> I have a minor detail
<fantasai> Have we covered the transition from old to new?
<jmkg> something that Paul and I discussed by private email
<Gerv> (My point about decision making applied only to URI. The final decision process may be different for each point. E.g. staff decide the skin.)
<Gerv> fantasai: I think jmkg and I got that sorted in the email.
<Gerv> But...
<Gerv> 9) How we transition
<jmkg> we basically agreed that in terms of skins, we should go for one with css, and one without css, so we can "show mozilla of" with the css skin, and "work in Nav4" in the non-css one
<Gerv> jmkg: Almost.
<Fabian> I have a question
<Gerv> The "non-CSS" one has to be the default,
<Gerv> so it could have _some_ CSS.
<Gerv> Otherwise it might look terrible.
<jmkg> er
<jmkg> we could browser sniff on that matter
<fantasai> If everything can be done in one skin, is that acceptable?
<Gerv> Our target is v.4 browsers and up.
<Gerv> fantasai: It is...
<Gerv> but I think someone will want to do a whizz-bang show-Moz-off skin.
<jmkg> fantasai: as Paul pointed out, it would be a miricle
<Fabian> Which of those 8 points discuss the structure of the index pages? (i.e. where each component will be linked)
<Gerv> Fabian: I think that's a bit further down the road.
<Gerv> We can prototype, right?
<jmkg> well
<Fabian> fine with me
<jmkg> some layout of index pages can be proposed
<jmkg> later ;)
<jmkg> I mean the pages, not where the pages are
<Gerv> Any more for the list?
<Fabian> yes
<hwaara> I have this one: What about decision making in this very process of specing out the site? Do we go by concensus or divide up departements that will take responsibility for specific decisions?
<jmkg> can we identify who on the staff list can do what?
<Gerv> Exactly what sort of decisions do you mean?
<Gerv> jmkg: staff list? You mean
<jmkg> i.e. coders, htmlers, UI experts, etc
<jmkg> Gerv: no Us
<Gerv> Oh, I see :-) Areas of expertise.
<hwaara> Everything. URI structure, design issues. Everything.
<jmkg> yeah
<Gerv> Yeah, let's do that.
<jmkg> I'm hopeless at graphics
<Fabian> 10) Has the CVS-to-HTTP bridge to ease the contributions been definitely voted out?
* Gerv clarifies
<Gerv> Let's do that via email.
<jmkg> Fabian: CVS is not used in Zope
<Gerv> CVS to HTTP is not necessary.
<Fabian> oh great then :)
<jmkg> Fabian: Zope has it's own versioning system
<Gerv> And I don't think Zope supports it anyway.
* Fabian is a zope peon, don't mind me :)
<Gerv> Zope's versioning system is sadly not quite all it could be.
<Gerv> But I hope that dawn, who cares about this stuff, will see it's good enough.
<Gerv> (For example, it has no conflict resolution, so only one person can work on a doc at once.)
<jmkg> we can see who did what and back them out (multiple undo) so it's good enough
<jmkg> so
<jmkg> um
* hwaara thinks this meeting should be moderated somehow. (not in IRC terms, but discussion terms...)
<jmkg> can I suggest these points be maintained the web? like my members area?
<Gerv> Any more for the list?
* Gerv makes the last call
<Gerv> jmkg: Good idea.
<jmkg> can we all agree on using HTML 4 Strict/
<jmkg> ?
<Gerv> nooooo!
<Gerv> No discussion yet!
<jmkg> aarrggh
<jmkg> haha
* Gerv is afraid of getting sidetracked.
<jmkg> lemme go do this points on the web then
<Gerv> Are we sure that list is complete?
<jmkg> if it's not I can edit it
* Gerv wants to practice publishing with Zope
<Gerv> Can I do it?
<jmkg> I'm doing it :)
<Gerv> Given we are starting from scratch, can we unclutter the place
<Gerv> by deleting most of the imported content?
<Gerv> It's got no metadata, so it would need to be reimported anyway.
<Gerv> We just need to leave enough to test skins.
* fantasai has no objections
<Gerv> OK. In what order are we going to discuss points 1 through 9?
<Gerv> 1 and 2 just need to be borne in mind.
* hwaara is looking at the URI structure on fantasai's site.
<Gerv> We can't really talk about them now - people need to go away and think.
<Gerv> 3) needs a lot of thought, and consultation with staff@ anyway.
<fantasai> Decision makeing first
<Gerv> 4) We could talk about skinning guidelines, and who we want to invite to make skins.
<Gerv> 5) Will get built up as we go along.
<Gerv> 6) is a biggie.
<Gerv> 7) Rather depends on Zope's capabilities - we can work it out later.
<Gerv> 8) needs discussion.
<Gerv> 9) I think we have that nailed in mail.
<Gerv> So it's 4, 6 and 8.
<Gerv> Is that right?
*** Signoff: hwaara ( has left IRC [Ping timeout: 180 seconds]
<Gerv> Er...
<jmkg> aha!
* Gerv clears out the root folder
<jmkg> got structured-text to produce a numbered list
<Gerv> Well done.
* Gerv goes looking for munchies
<jmkg> Thank you.
<Fabian> argh is down
<jmkg> or perhaps
* Gerv falls of his chair
<Gerv> JTK just did something useful!
*** hwaara ( has joined channel #web
<Fabian> no!
<Fabian> impossible!
<jmkg> JTK?
* hwaara got timed out.
<Fabian> Gotta leave for a while
<Fabian> I'll be back in a couple of hours
<Gerv> He did a scan of the tree to see what was under what license.
<Fabian> Thanks for the discussion :)
<Gerv> jmkg: The second URL's the right one.
*** Signoff: Fabian ( has left IRC []
<jmkg> yeah I thought so
<hwaara> What are we discussing.
<jmkg> one of the points on that list
* Gerv notes he gets to edit jmkg's front page :-)
* jmkg notes he gets to edit Gerv's front page :-)
* Gerv thinks perhaps Manager status should be quite restricted :-)
<jmkg> heh play nicely and we won't have any problems
<jmkg> so, which is first?
<jmkg> and what's "IP"?
<fantasai> intellectual property
<Gerv> Intellectual Property.
<Gerv> Well, we need to talk about 4, 6 and 8.
<jmkg> licensing you mean
<jmkg> I remember now
<Gerv> And other related issues.
<Gerv> How about tackling content standards first?
<Gerv> (Number 8)
<jmkg> ok
<Gerv> If I can pontificate for a moment...
<jmkg> we talking quality of code or quality of content ;)
<Gerv> staff are concerned that, having removed the barrier to entry that is CVS,
<Gerv> we don't establish new ones with quality and review bars.
<hwaara> Agreed.
<fantasai> W3C can review the HTML
<Gerv> On the other hand, our website is our window to the world, and we can't have any sort of rubbish on it.
<hwaara> Let's make it as simple as possible to contribute.
<jmkg> agreed
<Gerv> This dichotomy can partly be eased by the fact that
<hwaara> That's important if we want users to contribute.
<Gerv> anyone can stick anything they want in their Members area.
<Gerv> IF it's good, it can move to another part of the site later.
<Gerv> I should also point out that the DOCTYPE of pages
<hwaara> Sorry, I am not introduced to the Zope stuff; Members area?
<Gerv> is defined by the skin.
<Gerv> People sign up for the website and get a login.
<Gerv> They then have a members area at
<Gerv> Stuff under that they can edit as they choose.
<hwaara> So people can have host their website?
<Gerv> Sorry, I need to clarify.
<jmkg> I guess staff could
<jmkg> not sure normal users could
<Gerv> Hang on, there's something I'm not clear on here.
<jmkg> shoot
<Gerv> This must be a roles issue.
<Gerv> We need to allow anyone to get an account, so they can change the skin.
<jmkg> correct
<Gerv> However, I think we definitely need to have a privs level above that that allows /members/ posting.
<Gerv> Right?
<jmkg> wel
* Gerv isn't sure if that's built into the current model.
<jmkg> we want "Members"
<hwaara> Hm
<jmkg> we want "Staffers"
<Gerv> Ah, I get it.
<jmkg> Managers
<jmkg> right?
<jmkg> Staffers can publish and review content
<Gerv> Anyone can _create_ content but, if they are a Member, it doesn't get mde
<Gerv> world-visible without the signoff of a Reviewer.
<hwaara> sounds reasonable.
<Gerv> If they are a Contributor, it just becomes visible.
<Gerv> (this is the current workflow).
<fantasai> If something's reviewed, should it stay in the member's area?
<Gerv> Depends what it is.
<jmkg> right but that doesn't mean that Fred Bloggs won't come along, see they get their own account, post 100Mb of mp3s then tell everyone without knowing they can't get it
<hwaara> I was thinking of that
<hwaara> We need someone to approve Member accounts.
<Gerv> jmkg: I'm sure has come across this issue.
<hwaara> For people that have been around, that they can trust.
<jmkg> we want Members to be able to personalise content but not do ANYTHING else
<hwaara> Kind of like
<Gerv> We'll ask them how they cope with it.
<Gerv> Anyway, we got sidetracked.
<jmkg> we want Contributors to be able to publish content
<Gerv> I was sayign that the DOCTYPE is defined by the skin.
<jmkg> and then possibly Reviewers, then Managers
<Gerv> This is good because we can have a different DOCTYPE for the Mozilla-cool skin.
<Gerv> However, it means the _content_ has to be able to work with a number of DOCTYPES.
<fantasai> What's the problem with HTML 4.01 Strict?
<Gerv> If one of the DOCTYPEs we are going to pick for a skin is a STRICT one,
<Gerv> all the site content has to validate as HTML 4 Strict.
<fantasai> Please.
<hwaara> Why do we want people to have their personal stuff on Isn't this website supposed to host useful information, code and documentation _about the project_?
<Gerv> fantasai: the default skin may want to be transitional.
<fantasai> Why?
<jmkg> if one of the skins uses XHTML,
s in the content won't work :)
<Gerv> hwaara: Who said personal stuff would ever pass review?
<Gerv> Check out the members area.
<Gerv> There's all sorts of stuff there relevant to Zope.
* Gerv mentally adds XHTMLDocument to the content types list
* hwaara searches
<fantasai> Wasn't HTML 4.01 Strict agreed upon as the authoring doctype a while ago?
<jmkg> We could of course see how far "structured-text" can be used for content
<jmkg> it WILL be painful
<jmkg> but it is a possible solution
<Gerv> fantasai: All decisions made previously are being re-examined (and I don't think that was one anyway.)
<jmkg> it involved wiping the HTML out though
<fantasai> It was a general consensus, IIRC.
<Gerv> jmkg: I believe structured text gets transformed into HTML 4 Strict.
<jmkg> ah well then
<Gerv> At least, when I read the doc, all the tags it said it inserted were Strict ones.
<Gerv> So that's not a problem.
<jmkg> why not make 4.0 Strict stricly the only doctype UNLESS the entire page is *designed* for something elsde
<jmkg> i.e. one for XUL
<hwaara> Ok, so does anyone have an example of what a page may contain?
<Gerv> The DOCTYPE is defined by the _skin_, not the page.
<Gerv> hwaara:
<Gerv> :-)
<hwaara> Hmm
<Gerv> My assertion is that all content needs to be HTML 4 Strict
* fantasai seconds that
<jmkg> Gerv: yeah and ALL skins MUST conform to HTML 4 Strict. That's the answer
<Gerv> _because_ this gives us the flexibility of having a Strict or a Transitional skin,
<jmkg> and all content
<Gerv> if either are considered necessary.
<jmkg> well yeah of course
<Gerv> If the content is Transitional, we can't have a Strict skin.
<jmkg> if someone wants to make a Nav 3.x skin using Transitional fine, but they won't be allowed to touch content
<jmkg> rihgt
<fantasai> good
<jmkg> is that settled?
<jmkg> all content in HTML4 Strict?
<Gerv> Yep.
<fantasai> yep
<jmkg> GOOD
* jmkg updates the tasklist
*** Mode change [-o hwaara] on channel #web by fantasai
<Gerv> But skin-specific bits can be Transitional if someone makes a skin like that.
*** Mode change [+o hwaara] on channel #web by fantasai
<jmkg> Gerv: yes
<Gerv> This means we can cope with browsers who react badly.
<jmkg> oh
<Gerv> People set their prefs to the Transitional skin.
<jmkg> and can make the decision right now that we TEST the pages where time permits to ensure they validate?
<Gerv> The page validating will be a condition of uploading it.
<Gerv> It'll be in the migration docs
<jmkg> is all that under "Content Standards"?
<Gerv> Yep.
<jmkg> ok
<Gerv> (But if stuff slips through the cracks, I know some people will come round and fix it. Enough people have already volunteered for
<Gerv> So, content standards:
<Gerv> Pass through HTML Tidy to make it valid HTML 4.01 Strict.
<fantasai> Can it be hand-coded to HTML 4.01 Strict?
<Gerv> Use our site-wide style sheet (to be written) to style things.
<Gerv> Yep. No reason why not.
<Gerv> But it still has to pass the validator.
<fantasai> of course
<Gerv> Proper spelling and punctuation. We can nick some style guide bits from
<Gerv> Three letter extensions on resource names are discouraged except for URL backwards compatibility.
<hwaara> I don't think we should be too picky about that. After all, we should be glad that the user/whatever even bothered to contribute.
<hwaara> (spelling etc.)
<Gerv> Are we going to go for dash-separated or InterCaps?
<Gerv> Most people go for InterCaps on, I think.,
<Gerv> It seems the in thing at the moment.
<fantasai> For what?
<jmkg> er
<jmkg> no
<jmkg> everything in lower case please
<jmkg> PLEASE
<hwaara> Why?
<fantasai> It's easier to remember
<Gerv> Why?
<jmkg> I don't want to have to CHECK if a url has any characters in upper case or not
<Gerv> OK.
<hwaara> Ok, lowercase is fine by me.
<jmkg> it's also inconsistent
<Gerv> Dash-separated t is.
<hwaara> yep
<jmkg> dash-seperated?
<hwaara> dash-separated lowercase.
<jmkg> oh
<hwaara> reviewing-guidelines.html
<jmkg> i see
<hwaara> for example.
<jmkg> no extensions though
<jmkg> foo/bar/reviewing-guidelines
<Gerv> Yep.
<hwaara> Does zope add that by itself?
<Gerv> jmkg: Here's more Structured Text practice.
<Gerv> Link to README-style in your doc.
<Gerv> No. Extensions are _bad_.
* Gerv doesn't want to have this discussion
<Gerv> Take our word for it, OK? :-)
<jmkg> thats what I said
<hwaara> sigh
<hwaara> ok
<Gerv> I was talking to hwaara
<Gerv> Someone dig out the W3C document for him.
<fantasai> Link to
<hwaara> Nevermind
<fantasai> too
<hwaara> It's hard as it is keeping up in this chat
<jmkg> ugh ugh ugh two min break
<jmkg> fantasai: what's that page?
<fantasai> Henri Sivonen's guidelines for cleaning up pages
<Gerv> mozorg2strict is cool.
<Gerv> That should be in the migration guidelines.
<hwaara> Where are these guidelines?
<Gerv> We're writing them :-)
<Gerv> (Point 5) of my list)
<hwaara> And how do I gain access/knowledge to all the stuff
<Gerv> You create an account on the front page.
<Gerv> And read up about zope at
<jmkg> erk
<hwaara> What's next on the list?
<Gerv> Are we done with 8) Content Standards?
<hwaara> Does that include document contents, or is that skins
<jmkg> Gerv: I'm just trying to complete that bit of the page, hold on
<jmkg> Gerv: getting to grips with structured-text "live"
<Gerv> Document contents.
<Gerv> There's a skin HOWTO under number 4).
<jmkg> uh?
<jmkg> * Skins and skins HOWTO
<jmkg> (4)
<jmkg> ok take a look at the list page and notify me of changes needed while I grab my cup of tea
*** Fabian ( has joined channel #web
<jmkg> Fabian:
<jmkg> er
*** Mode change [+o Fabian] on channel #web by jmkg
<Gerv> jmkg: Add links to the validator, and mention HTML Tidy as a useful tool to aid migration.
<Gerv> But otherwise that's cool.
<Gerv> Oh, hang on...
<Gerv> Add the other stuff.
<Gerv> Link to the style guides,
<jmkg> other stuf?
<Gerv> and say we're taking the styling stuff out of that...
<jmkg> as in getting rid of them?
<Gerv> We are using dash-separated file names?
<Gerv> No, as in using, sorry.
<jmkg> erm
<jmkg> this is not easy as I can't put breaks inside numbered lists
<Fabian> What is the current topic?
*** jmkg has changed the topic on #web to " website tasks"
<Gerv> jmkg: Switch to HTML, then :-)
<Fabian> Gerv: I got your mail about Bug Sheets
<Fabian> Gerv: I got a problem with my smtp right now so I couldn't answer
* Gerv can't remember that mail
<hwaara> I am interested in 2)
<hwaara> Workflow / roles.
<Gerv> Do you think the default workflow won't work?
<Fabian> Gerv: one week ago or so
<jmkg> erm
<hwaara> Gerv: I was more thinking about roles, if that implies assigning people different kinds of tasks depending on their "role".
<jmkg> I'm hitting lots of bugs in mozilla's textarea widget here
<Gerv> There are lots.
<Gerv> hwaara: right. We currently have:
<Fabian> I'm having a damn problem with Mozilla to send mail... it's hanging every time
<Fabian> arrgh
* Gerv can't find the list of Roles in zope
<jmkg> anyone have a url to the moz style guidelines?
<Gerv> never mind.
<Gerv> The point is: if you have a problem with the default workflow, say so on the list.
<Gerv> Number 4) - Skins.
<Gerv> Basically, we have to define a) some guidelines and b) who we are going to give permissions to to make some for us to look at.
<Gerv> Or I should say "offer" because they might be too busy :-)
*** fantasai_ ( has joined channel #web
<Gerv> hwaara: huh?
<jmkg> erm
<Gerv> Ah. fantasai: what did you miss?
<hwaara> Hm
<jmkg> webpage updated
<hwaara> I don't think we are talking about the same type of skins, do we? :)
<jmkg> as for skins
*** Signoff: fantasai ( has left IRC [Ping timeout: 180 seconds]
<fantasai_> I spoke, and then I lost the connection
<jmkg> can I point out that the global navigation points need to be set in stone
*** fantasai_ is now known as fantasai
<jmkg> like, "main navbar on the left in it's own table cell" or whatever
<Gerv> Why?
<hwaara> Because consistency is good.
* fantasai doesn't like layout tables
<Gerv> That gives no flexibility to the designer,
<Gerv> and reduces creativity.
<Gerv> Oh, I see what you mean.
<Gerv> You mean throughout the site?
<jmkg> because it may impact on the sizing and positioning of content, and consistency
<hwaara> is not :)
* Fabian doesn't like layout tables :P
<jmkg> I don't care, we just need rules
<Gerv> jmkg: There's a big difference between sayingL
<fantasai> Other than the default skin, we should not define layout restrictions
<Gerv> "All skins you design must have a left navbar" and
<Gerv> "All skins should have consistent navigation
<Gerv> ".
<Gerv> The first is wrong, the second is right.
<jmkg> if a designer wants to go absolute positioning that's fine, so long as the content is given a consistent "window" and the navigation bar is in the "right" place
<Gerv> But also obvious.
<hwaara> the question is how much restrictions we want to enforce. if it's "all text should be blue" or "please use english". There's a slight difference. :)
* Gerv doesn't understand what jmkg is going on about with consistency
<Gerv> How do you expect the designer to put it in different places on different pages?
<Gerv> They aren't skinning each page by hand!
<hwaara> true
<jmkg> actually
<jmkg> exactly what does a skin contain?
<jmkg> links?
<jmkg> or just presentation?
<Gerv> Look at the skin tool.
<Gerv> It can contain anything.
<Gerv> Or nothing.
<jmkg> i mean, if s/he does a skin that includes the links from a central html doc...
* Gerv doesn't understand that sentence
<jmkg> well
<jmkg> if we put all the links as html:
  • home page
  • news
  • etc
and save that into /main-links.dtml
<hwaara> Gerv: please clarify the zope stuff before starting a discussion on it for us non-zopers.
<jmkg> the skins can use I think and have them automatically included
<Gerv> hwaara: You need to do some reading, then :-)
<jmkg> I'll be back in ten mins, gonna grab a quick shower
<Gerv> This discussion rather involves knowing a bit of something about Zope.
<Gerv> Adjourn for 10 minutes! (Time for Hwaara to read the Zope Book ;-)
<hwaara> Sure, I will read it, but I can't right now.
<Gerv> jmkg: Different skins may have different main links.
<Gerv> hwaara: what else were you planning in the next 10? ;-)
<hwaara> This chat?
<Gerv> jmkg: For example, a developer's default skin may be different to the one we present to anonymous visitors.
<Gerv> We're adjourned :-)
<Gerv> (jmkg is taking a shower.)
<hwaara> By the looks of it, it's more than 10 mins of reading.
* hwaara reads
<Fabian> bah had to create a new profile to get my smtp working agai
<jmkg> back
<jmkg> Gerv: do you have a link to some skins docs?
* Gerv wakes up
<Gerv> No. People will have to search and
<fantasai> Gerv: the 6-7 top level categories are not defined per skin
<Gerv> Making a skin won't be trivial - which is good, because anyone who does one will be a serious player.
<Gerv> fantasai: Well, yes and no.
<Gerv> The URL structure definitely isn't,
<Gerv> and the front page navigation is a cousin of the URL structure.
<Gerv> But there's some flexibility.
<Gerv> For example, there might be a developers' skin,
<Gerv> which has useful day-to-day links for developers
<Gerv> more prominently than the default.
<fantasai> sure
<Gerv> But yeah, we should decide the default set.
<fantasai> But those 6-7 links shouldn't change
<fantasai> The main ones.
<Gerv> If skin authors need to vary, they'll have to justify.
<fantasai> Because the site's structure isn't going to change by changing the skin
<Gerv> fantasai: that's not even true. I think the front page should have Get Involved as 1 of the 7, but the dev skin wouldn't.
<Gerv> It's slushy, but not frozen.
<fantasai> gerv: this is getting into URI structure.
<Gerv> No, what I said was exclusively and exactly a skin issue.
<fantasai> Depends on what goes in Get Involved
<jmkg> hahha
<jmkg> gawd
<Gerv> I said on the list that the top level links and the URI structure do not need to be a flat map.
<Gerv> For example, Get Involved could be a top level link,
<jmkg> can we stay away from this please
<Gerv> but it could live in /community/get-involved//
<jmkg> the fact is, skins can do this
<jmkg> full stop
<fantasai> yes
<Gerv> jmkg: As a general point, can you please be more specific? :-)
<jmkg> lol
<Gerv> I think I know what you meant.
<jmkg> shut up
<jmkg> bingo
<Gerv> The current topic is skinning guidelines.
<jmkg> now does the topic link contain everything we want up to this point?
<jmkg> uh
<jmkg> it is?
<Gerv> What do you think it is?
<Gerv> (Well some of the stuff under Content Standards should be under Migration HOWTO, but they are related, so it's not a big deal.)
<jmkg> I had no idea, I was concentrating on the web doc
* hwaara can't keep up
<Gerv> It is, I promise.
<fantasai> jmkg: Could you use outline format, please? (lists instead of br)
<Gerv> hwaara: We've been here for three hours now.
<jmkg> yeah
<Gerv> I have to go soon.
<fantasai> same
<Gerv> If we went any slower, we'd be here all day.
<hwaara> i'm swamped. sorry.
<Gerv> NOW... :-)
<Gerv> Skin guidelines.
<Gerv> People fire ideas :-)
<Gerv> 1) All lizards are red
<Gerv> 2) Use the top-level links we define, wherever you decide to put them (we are assuming they are defining the default skin)
*** fantasai_ ( has joined channel #web
<fantasai_> Skins need to link in a site-wide persistent stylesheet.
<fantasai_> Styles can be overridden.
<Gerv> Yep.
*** Signoff: fantasai ( has left IRC [Ping timeout: 180 seconds]
<Gerv> Well, the site-wide style sheet needs to define the same named styles/
<fantasai_> They must define a .shaded style rule
<Gerv> Quite what they _do_ is up to the skin designer.
*** fantasai_ is now known as fantasai
<Gerv> (e.g. they might be forced to define .important, .note etc., but could define them how they wanted.)
<fantasai> If we write one stylesheet which all skins must link to,
<fantasai> that will be done.
<Gerv> We need to decide what those are - but I guess we just pinch
<fantasai> And they can override the default values
<fantasai> Just parts of it.
<Gerv> Oh, I see. Yes.
<fantasai> Most of it isn't needed
<jmkg> hrm I'm gonna create another specs doc for this one
<Gerv> jmkg: Just throw it all in the pot.
<Gerv> It doesn't matter at the moment.
<Gerv> It'll get split up eventually.
<Gerv> If you are doing that, it really needs to be about five different docs.
<jmkg> I know
<Gerv> Any more?
<jmkg> hold on
<jmkg> erm
<jmkg> we need a submissions procedure
<jmkg> do they download something, develop on their own server, then upload something to us?
<Gerv> For skins? No, because everyone we give permissions to create one to, will create one :-)
<Gerv> They are developed on the server as I understand it.
<jmkg> ok
<Gerv> Who do we offer permissions to?
<jmkg> so they ask us for "skinning perms"
<Gerv> Sort of.
<Gerv> Henri Sivonen
<jmkg> we say, "can we see some of your web design work"
<Gerv> Axel Hecht
<jmkg> they say, "sure, url url url"
<jmkg> we say, "cool! get to it!"
<jmkg> they do it
<Gerv> Good plan, Stan.
<jmkg> they send in a link or whatever for us to review
<Gerv> Let's go with that.
<jmkg> we review it, give feedback, and continue to review until we say, that's good enough
<Gerv> Can you write up the Skinning Guidelines and post them as an independent doc?
<jmkg> I am already
<Gerv> Then we can post to asking for volunteers.
<Gerv> That post will be politically sensitive, and probably staff@ will want to vet it, so I'll sort that out.
<jmkg> the skin author may add their name as the credit to the bottom of the page
<Gerv> That's a detail.
<Gerv> OK, 2 out of 3 aint bad.
<Gerv> You can get the stuff we agreed about migration paths in mail and add that in.
<Gerv> (You may want to stop using Structured Text at some point, or learn some more, because this is getting unwieldy.)
<Gerv> I'm sure you can do paras within bullets.
<Gerv> Just URI structure to decide, then :-)
<Gerv> That won't take long.
<Gerv> ;-)
<Gerv> OK? I'd like to go into Mountain View.
<Gerv> jmkg?
<jmkg> um
<Fabian> OK so what can I do to help? Any content doc needs to be written?
<jmkg> how's that?
<Gerv> There is a default skin that we have created.
<Gerv> There is a default skin that we have created.
<Gerv> to
<Gerv> There is a default skin that we have created.
<Gerv> Oops.
<Gerv> I mean:
<Gerv> A default skin needs to be created.
<Gerv> (Since that's what they are doing)
<jmkg> but that won't last lone
<jmkg> er long
<Fabian> jmkg: the url gives me a password boc
<Fabian> jmkg: the url gives me a password box
<jmkg> oops
<Gerv> Ah. Hang on.
<jmkg> try now
<Gerv> You need a login.
<fantasai> try now
<Gerv> Log in on the front page.
<jmkg> ah
<jmkg> try
<Gerv> jmkg: Can you remove the procedural details?
<jmkg> ?
<Gerv> They'll a) be in the email and b) some are not how it's going to work.
<jmkg> oh what until it's cleared
<Gerv> Yeah.
<jmkg> ok
<Gerv> Remove my "vague" comment.
<fantasai> Why multi-search on all pages?
<Gerv> Add "See the current front page
<Gerv> for details" to 5).
<fantasai> Just a website search should be enough, no?
<Gerv> fantasai: It needs to be on the front page.
<fantasai> oh
<Gerv> Lots of people have told me it would be cool to have integrated searching.
<Gerv> But you are right.
<Gerv> It shouldn't be a requirement.
<jmkg> erm
<Gerv> I think we want search on every page, though.
<fantasai> yes
<jmkg> See the current front page for details <-- add as an item, or what>?
<Gerv> Add it to the end of point 5).
<Gerv> We also need to make the site-wide sheet.
<jmkg> You'll need the Zope admin links (login etc.) <-- there?
<Gerv> fantasai: Can you modify persistent-style.css appropriately and forward to the list?
<jmkg> oh as another item
<Gerv> jmkg: Yes.
<fantasai> yes
<Gerv> jmkg: No.
<Gerv> As the second sentence for that item.
<jmkg> You'll need the Zope admin links (login etc.) See the current fron...
<jmkg> ?
<Gerv> Document in the file which ones shouldn't be overwritten.
<Gerv> jmkg: Yes!
<Gerv> We also need to define the top-level links and put them in that document.
<Gerv> That's not quite true.
<Gerv> We need to define _some_ top level links,
<Gerv> given that if there are 7 in a design, it doesn't matter which seven - it can change.
<Gerv> So the skins don't have a dependency on that flamewar.
<fantasai> pick random seven links
<fantasai> six, rather, plus "Search"
<Gerv> So we can change 2) to read: there should be room for 7 top-level nav links.
<Gerv> If there's a search box, we don't need a Search link.
<Gerv> And 8) We reserve the right to change this list at any time. :-)
<Gerv> jmkg: Remove 4).
<Gerv> It's superceded by 8.
<Gerv> Don't mention procedural details at all.
<Gerv> 6) s/a/the/.
<Gerv> Remove 10).
<jmkg> A site-wide styleshe..?
<jmkg> remove?
<jmkg> gerv
<Gerv> 10) is covered by 6 and 7.
<Gerv> So it's not necessary.
<Gerv> Sorry.
<Gerv> It's now 9).
<jmkg> reload
<Gerv> Looks good to me.
<Gerv> Everyone?
<jmkg> yup
<Gerv> You still haven't fixed the opening sentence.
<Gerv> There is a default skin that we have created.
<Gerv> ->
<Gerv> We need to create a default skin (although other skins can be made and will be available.) Here are the guidelines:
<jmkg> "The default skin needs creating"
<Gerv> s/All lizards are red/Any lizards present should be red./\
<jmkg> reload
<Gerv> Add at the bottom.
<Gerv> 8) We reserve the right to change these at any time.
<Gerv> And then a paragraph:
<Gerv> Other than that, you have full artistic control.
<Gerv> Now I must go.
<jmkg> done
<Gerv> We'll talk about the more controversial stuff another time.
<Gerv> But it was good to get that lot out of the way.
<jmkg> ok thanks
<fantasai> Can we discuss URIs on the list?
<jmkg> I'll send a note to the list with these urls
<fantasai> Rather than in here.
<Gerv> s/these/these guidelines/.
<Gerv> fantasai: Yep.
* Gerv goes
<Gerv> Thanks everyone :-))
<fantasai> thanks, Gerv :)
<Fabian> thanks Gerv
<jmkg> Meeting Adjurned