D'oh --
Looked at the history page in more detail and saw the improved
functionality. Please ignore, disregard, and accept my humblest
apologies for the last letter!
Jules
A relatively new contributor, Ellmist, has been adding articles
about Robert Heinlein's novels. This is a good thing - Heinlein
was an important sci-fi writer, and we should cover his work in
some detail.
However, they have added the publication dates of his books
to the applicable "Year In Review" articles. Is this such a
good idea? Probably not. I doubt that everything Heinlein
wrote was so momentous to warrant such a listing.
This is a more general problem with the year in review listing.
Unlike virtually everything else in the 'Pedia, these articles are
space-limited by their very intention (to provide a concise overview
of what went on in the world in that year). Therefore, if we wish
to retain them in the current form, we're
going to have to exercise editorial judgement as to the things
sufficiently important to list there.
The NPOV isn't a great help here. It says we should resolve disputes
by by characterising the
dispute and letting the differing opinions speak for themselves.
I can't see how that helps. Because we are space-limited, we *can't*
just list every event that somebody (or even a large group of people)
thinks is important, state why those people think it was important,
and let the reader come to their own conclusions.
Lists like this are a special case, and so I would argue that we should
make special rules to handle it. What those special rules should be I'm
not sure. As a "meta-rule" I think we need fairly strict section
guidelines on what can go into each section of the Year in Review
entry.
Let me play Devil's advocate for a minute. The fact that we might need
special rules for Year In Review articles makes me wonder whether
they are, indeed encyclopedia articles or something else entirely.
If not, do they really belong as part of the Wikipedia or are they
a job for another projct with different rules? Probably not, but it's
something to think about.
Opinions?
-----------------------------------------------------------
Robert Merkel rgmerk(a)mira.net
Go You Big Red Fire Engine
-- Unknown Audience Member at Adam Hills standup gig
------------------------------------------------------------
How do I make a link to a sound? I just uploaded a recording of a morepork
(Ninox boobook) (No copyright on birdsong) and tried to link to it and it
didn't work.
phma
On Tuesday 23 July 2002 04:12 pm, you wrote:
> Does it:
> * preserve what you like about Cologne Blue's looks?
> * have the menu items in roughly logical and familiar positions?
> * work on your browser?
>
> Please feel free to suggest changes: this is a work in progress.
>
> Regards,
>
> Neil
I like it - very logical sidebar layout. I couldn't find the talk link but I
think that it would be best to group it along with everything currently under
"edit" and under "page options" under a single heading called "this page" or
even reuse "page options". This way 'what links here' will be grouped with
'watch links' which I think is more logical than having them separate.
I can't say much about the rest of the layout because it is badly broken in
Konqueror 2.2.2 and Mozilla 0.9.8 but this is probably my fault so don't
consider this a bug just yet.
--mav
This is a hacked version of Marian's Cologne Blue layout. I've tried to
address some of the criticisms of Cologne Blue as a default skin, whilst
preserving as much of the niceness as I can.
It is intended to
* use the browser's native font settings for text and menu link items
* show my proposed "ergonomic" layout of side menu items based on
analysis of the stats from the new server
* otherwise preserve the "clean" feel of Cologne Blue.
The principles for the menu item ordering are:
* Menu item groups are organised by the scope of what they refer to
(global, this user, this page, etc.)
* Menu groups are organised from top to bottom by frequency of overall use.
*Where there are significant differences in frequency within a group,
entries within that group are listed in order of frequency of use.
*otherwise, entries within groups are ordered alphabetically.
Notes/disclaimers:
*This is a visual mock-up only.
*The links don't work, and are generally wrong or nonsense.
*This was hacked together in Mozilla's Composer module, which is a poor
tool for editing complex HTML.
*It still uses tables for layout.
*The HTML is tag soup, and probably won't validate.
*I've only looked at this layout in Mozilla 1.1beta and Internet
Explorer 5.5.
If anone likes this, I can extract the design, and write some valid HTML
+ CSS that can be used as a template for a new server skin.
Please let me know if you like the layout.
Does it:
* preserve what you like about Cologne Blue's looks?
* have the menu items in roughly logical and familiar positions?
* work on your browser?
Please feel free to suggest changes: this is a work in progress.
Regards,
Neil
On Tuesday 23 July 2002 03:41 pm, LDC wrote:
> Along those lines, I've had enough requests to restore the "show only
> new changes" feature, and that feature can actually speed up the
> database query, so I plan to put that back.
Coolness -- much thanks!
> The tricky one is consolidating multiple edits to a page into one
> entry on the Recent Changes page, the way UseMod and Phase II did.
> This is a big performance hit. Perhaps a later redesign of the
> database would make it more reasonable, or perhaps a new
> implementation will come to mind that cures the problem, but for now
> I just don't want to burden the server with extra work for what is,
> to me, a cosmetic change that doesn't add functionality.
Please don't significantly compromise performance for cosmetics no matter
what anybody says or pressures you to do (including me). I know I offered
this idea as a feature request but my intent was to gain some of the article
edit organization that the previous software had and I hadn't a clue about
the performance hit you mention. But since you are going to reimplement "show
only new changes to articles" I don't think the grouping feature would be
worth any significant performance hit.
--mav
> Could someone perhaps design a CologneBlue Mk2, with the
> following changes:
>* serif font
>* clearer toolbar
>* key links along the top
>* include the wikipedia logo
>
> I agree with all the objections to CB, but I also agree with the
> need for a cleaner-looking interface to welcome newcomers.
It's pretty straightforward to write a new skin now--check out
the files "SkinCologneBlue.php" and "cologneblue.css" from the
code. I tend to agree that we need one that looks clean like
Cologne Blue but that's more usable.
But I know my own limitations well--I'm a coder, not an artist.
So if someone designs a skin using some other HTML tool, and can
show it to me, I'll make the code do it. But I shouldn't be the
one designing it.
0
>> The tricky one is consolidating multiple edits to a page into
>> one entry on the Recent Changes page, the way UseMod and Phase II
>> did. This is a big performance hit.
> Do we have some measurements on this? Would it be worth the effort
> if I tried to come up with some SQL that did this for the new
> script?
I have only compared the actual query used in Phase II (with that
ugly LEFT OUTER JOIN and GROUP BY) with my present query (actually
two queries, because MySQL doesn't have UNION yet). If you want
to try other queries on the new database schema that might work with
comparable speed to the present one, I can try those out on my server
and time them using a version of Neil's bot.