Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index






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 website+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.