Hi Bernhard,
First, thanks for the level-toned and opinion-free response.
> If your expert doesn't want to be involved in discussions and proposals
> with experts and community members from other parts of the LibO
> community, his work can't be more than a proposal, perhaps used as
> starting point for a community based web design. Most likely he will
> find important parts (in his expert opinion) of his design modified and
> downgraded. As this might have an impact on your personal relationship,
> I want him to know this beforehand.
>
> But if he is interested in getting information about our needs, wants to
> join a collaborative effort to improve the website and is open to
> modifications caused by present community experience (especially in
> iterative improvements rather than general overhaul), he is more than
> welcome to propose his ideas.
The first approach is not viable (we NEVER work like that).
Approach#2 is how we routinely work.
Inputs from key stakeholders is essential (including marketing, design, UX team
AND copywriters).
After that, he would propose some "seed" designs, so that all members can
brainstorm.
(Normally designers do that to gauge the mood of their clients.)
Based on the discussion, he would make the final design (HTML code, icons).
There may be one or more rounds of this.
In other words, his work on this project would RELY on comprehensive inputs
from EVERYONE.
His output would be modulated based on stage-wise reviews by all stakeholders.
> Even if he doesn't want to stay longer with us, I think everybody will
> see his positive contribution (and if he likes the way we work - perhaps
> he reconsiders his decision...)
I hope so! :)
> In order to include his work in our efforts it would be necessary to
> license it under a proper OS license (CC by-sa 3.0 for the website).
Yes, I will convey this.
> *long version (covering some other topics too):*
[..]
> Our website needs to fulfill several different goals - attract curious
> people to become users or contributors, provide information to present
> users and contributors.
>
> The user groups are diverging, contributors work in very different areas
> - how can you describe the needs of our community to someone who doesn't
> know about our structure and the way we work?
That is why requirements from all stakeholders need to be collected.
Without that clarity, no website (-indeed any product-) can be designed.
> > And what has this to do with the OS model?? [...] Website
> > design is a specialized field, and even an OS project would have to
> > follow its norms.
>
> ... provided the designer knows about the preconditions mentioned above.
> Some of these conditions show up later on - just because they have been
> forgotten or not taken as serious as they should, some develop in
> future. They have to become implemented too - and evolving a design
> without the primary team is harder.
Yes, this is a frequent scenario in real-world web-design too. :)
> > Given that, they should not at least be a hindrance when we are
> > struggling to manage on our own. To be fair, I have not seen any
> > evidence that they would block us from doing any positive work.
>
> "On our own" might be problematic - because the website team is one
> (important) aspect of the overall community. But in general you're
> right: You will not be blocked, if the work is considered as positive
> for the community.
How can it be deemed otherwise, when the website would be designed with your
inputs and stage-wise consultation? :)
But there has to be a caveat:
Everyone should respect what a web-designer says about his field.
Do not try to foist outside concepts on web design.
If there is a disagreement, we settle it by referring to reference literature
on UX and web design.
(Like the link I quoted.) AGREED?
Also keep in mind the adage that a camel is a horse designed by a committee. :)
> >> Everyone wants the project to go forward - but often in different
> >> directions!
> >>
> >> There comes a time when we have to choose one path and then all
> >> contribute to it.
> >
> > That was my point: The current design is way off course - Both in
> > process and contents. See this checklist and decide for yourself:
> > http://www.abrook.com/website-design/website-planning-checklist/
>
> Thanks for this link - If I remember correctly, most of these points
> have been mentioned during our discussions here, but haven't been
> presented in such a good structure.
I am glad that multiple people have repeatedly asked for these SAME points!
It means that a majority of the group WANTS to follow that path. :)
> > [...]SC should give us a lab space. Like Google labs, we should
> > have an official idea-generation and prototyping area.
>
> With Pumbaa [1] there is already a staging site.
That page does not load! (connection times out)
> The SC decision not to support Drupal development during the next month
> has been based on the experience, that Drupal supporters worked on their
> site instead of the main LibreOffice site, they started a challenge
> between the two CMS and proposed Drupal solutions as the best way to
> handle several tasks in different teams while people having worked with
> other tools for some years didn't want to give up their tools.
>
> This led to numerous mails and discussions - with the result of a
> negative work/discussion ratio.
>
> To enable work again the SC decision to postpone Drupal development has
> been taken - and as Charles already stated: Please don't try to revert
> this decision before we have reached a final state of our website.
>
> It would lead to even more discussion and less real work...
Frankly I don't care about CMS at all.
At this moment, we must focus on creating a professional website.
CMS has nothing to do with this first phase.
After that, we must focus on how to deliver the desired functions for all
stakeholders, and how to create an integrated workflow.
That is what I proposed for the website team agenda.
In the wider context, choice of CMS would have an impact, because each CMS has
different "out-of-the-box" capability.
We should implement a website with minimum hacking, so that security is not
compromized.
Also, any local hacking breaks when the CMS or its plugins get updated.
But let us keep that brainstorming (not a face-off or debate, mind!) for later.
****
To sum up-
If we are clear about our workflow, I can request my colleague to come in and
help.
I'd like a clarity and consensus on this point, please!
Regards,
Narayan
--
Unsubscribe instructions: E-mail to [email protected]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
