[isf-wifidog] Re: [isf-vol] Nouvelle mise à jour de wifidog sur le serveur
bock at step.polymtl.ca
Jeu 30 Nov 18:19:48 EST 2006
> Best of all from my point of view, the stuff that helps us move
> forward with the portal page / content side of ISF.
The most significant part (I think) is one you didn't highlight: the
ContentReport, that finally allows us to measure how much people do/don't
interact with the various content we provide.
> You mention metadata for content being replaced by "something better",
> "best practices" for showing sponsor information, and editing the flow
> for content management. I know that you have loads of expertise in
> educational metadata and that you're busy, but I think it's important
> to again request for some way that myself, ISF in general or other
> people that work with online curating/exhibition, could give feedback
> on these features before they are developed.
There are various ways of giving feedback (verbally at meetings and
conferences, as tickets on the wifidog trac, on IRC or on the wifidog mailing
We frequently ask for it, but seldom get it. When we do, it does often
results in actual changes. In fact, all the examples you listed are the
direct result of feedback from organizations using wifidog:
- Getting rid of the sponsor field comes from the St-Louis conference.
- "Is artistic" and "Is locative" were removed because of a general concensus
that ways must be found to de-clutter the content manager admin interface and
because they will be made redundant by whatever content grouping evolves into
(and guess who's pushing on that ;).
- Changing the flow of the editing interface was done after feedback from
U2Com (a UK company that uses wifidog).
But people rarely notice that a specific change is the direct or indirect
result of their feedback, unless the feedback was through a ticket (the
ticket will be closed when the change gets in, and the person will get an
automated email). So some people are left with the strange impression that
the process isn't open to everyone.
Off course, the developers cannot agree with every suggestion. Sometimes
because they simply disagree (it does happen, but usually a compromise is
reached), but generally because implementing the suggestion would have
negative consequences on other parts of the system or difficulties/costs the
person who made it didn't/couldn't know about.
> For example, how will it
> be decided which metadata should be available for content pieces?
The short answer is the editor/curator of the different group should decide.
The very segmented metadata (Title, Description, long description, project
info, sponsor, author, locative, artistic) for the content manager came from
the very structured way we thought content would be curated back in the days
of our collaboration with MDCN 1.
Every piece of content displayed on the portal was meant to have the same
structure, and have visual similarity no matter it's nature (image, text,
feed, video, etc.): a large area for the actual content, with the metadata
around it. That way the user could at a glance figure out where the content
comes from, if it's artistic, locative in nature, who the author is, etc.
The "unit of interest" was supposed to be the content pieces, taken
individually, not the portal as a whole. so far that didn't work out too
-Few portals actually have large number of content pieces displayed at the
same time, so we have no significant userbase to give practical feedback on
these issues. Most simply do not yet encounter the problems that this
systems was meant to solve (content organization, consistent UI, distributed
curation). And when you have a portal with little content, it is perfectly
rational to be less willing to compromise on aesthetics to get better content
-These fields were meant to be labeled in the end-user UI. The labeling was
removed early on for aesthetic reasons (I bowed to the pressure, which may or
may not be a good thing). As such, most people using the content manager do
not care what the fields are for, just how they are displayed. I would love
to label them again, but I am under the impression that most people would
oppose it still (But, maybe I'm assuming too much about other people's
-Having a very structured form for metadata is no substitute for a proper (and
ideally enforced) editorial policy about metadata.
-We underestimated the huge headaches that groups of small units of content
(some RSS feeds, events and the like) would cause. They currently break most
ways we could otherwise groups content.
Deciding to get rid of the sponsor field was an easy decision: sponsors
information actually IS project information. If a group chooses to display
this info, having it in it's own field adds little (actually, it adds nothing
as long as the field's aren't labeled).
> sure that there are several of us that would like to be involved in
> these decisions, from NYCwireless, WT and ISF, and perhaps elsewhere.
> I'm not saying it's your responsibility to make sure those discussions
> take place (if anything, it would be Francois's job if he weren't knee
> deep in stuff at MIT).
Indeed. Feedback is solicited on a fairly regular basis, and rarely obtained
(even from ISF). But the "decision" process is most definitely open. In
fact so far we only refused a single patch: automatic node creation for
everyone. It was only refused until access control could be built into the
patch and the feature could be turned off for groups that didn't want it.
Unfortunately, not many people are willing to take the time required to give
constructive criticism on how the current system should evolve (rather than
we should start over with buzzword of the day, but they have no time to
help). Yet a lot of people are very eager to criticize features of wifidog
(sometimes very publically) when they don't do exactly what they want. Once
you start improving what they complain about, they frequently still won't use
it/comment on it.
But that is not unique to wifidog, nor to open source development.
Plus d'informations sur la liste de diffusion WiFiDog