[opensuse-wiki] Discussion: Article template and the way we present information
Looking how to document http://wiki.opensuse.org/Template:Article I looked on its functionality again and it seems that we have to rethink current layout and the way we want to present information to visitors. Currently actual content (6.) that wiki visitor is looking for is moved way below the first loaded screen. The order of page content is" 1. Discover it - solved in Bento theme 2. Navigation bar 3. Introduction to article 4. Knowledge section 4.1. Tested on 4.2. Recommended 4.3. Related 4.4. Used programs 5. TOC (table of contents) - it is too wide on the majority of pages 6. Actual article I have to scroll down even on 1920x1080 screen, and scrolling down in order to see text can become very fast annoying if it is present on every page. Not to mention my experience with one web page that should have lists of Linux compatible hardware. It has every page top section common to all articles, occupying whole browser page and a bit more. First I thought that top of the page is whole page and presents index to actual article (table), and after some clicking around, jumping from page to page, looking for actual hardware list, came on idea to check what is below, and surprise, there was a table. Some tables were only few rows, making whole page design funny looking. You can imagine what is my opinion about importance to present actual article text on the very first page load. All tools, indexes, cross links, tables of content should flow next to the article text, but never push it way below article title. First and the simplest idea is to compact navigation bar, intro and knowledge bar. The Related column of knowledge bar in this context is redundant as related articles should be listed in navigational bar. Navigational bar should be squeezed as much as possible. TOC should be separate column with fixed size, but not over whole screen, leaving enough room for intro and actual article beginning. Next idea would be to use a method similar to wiki.o.o portals, or template and its documentation, where the main page consists of one or more transcluded pages. This gives possibility to create few views of the same article with very little additional effort. In other words to create modules and then use them in the few articles, or as stand alone units. How to split article: 1) very short intro in article purpose (problem and offered solution) that can be published (transcluded) in a different content indexes and portals 2) longer intro (Knowledge) that will list mandatory skills and tools to accomplish task (prerequisites) 3) actual procedure or discussion 4) conclusion; what we accomplished and where to proceed 5) article reference index;list of related topics internal and external This proposal has to be tested with articles about few topics in real setup on a new wiki. I'm looking for the people that like idea and want to help me with comments, ideas, creation of proposals. -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
Rajko, 2010/3/1 Rajko M. <rmatov101@charter.net>:
Looking how to document http://wiki.opensuse.org/Template:Article I looked on its functionality again and it seems that we have to rethink current layout and the way we want to present information to visitors.
Currently actual content (6.) that wiki visitor is looking for is moved way below the first loaded screen. The order of page content is"
1. Discover it - solved in Bento theme 2. Navigation bar 3. Introduction to article 4. Knowledge section 4.1. Tested on 4.2. Recommended 4.3. Related 4.4. Used programs 5. TOC (table of contents) - it is too wide on the majority of pages 6. Actual article
I have to scroll down even on 1920x1080 screen, and scrolling down in order to see text can become very fast annoying if it is present on every page.
Not to mention my experience with one web page that should have lists of Linux compatible hardware. It has every page top section common to all articles, occupying whole browser page and a bit more. First I thought that top of the page is whole page and presents index to actual article (table), and after some clicking around, jumping from page to page, looking for actual hardware list, came on idea to check what is below, and surprise, there was a table. Some tables were only few rows, making whole page design funny looking.
You can imagine what is my opinion about importance to present actual article text on the very first page load. All tools, indexes, cross links, tables of content should flow next to the article text, but never push it way below article title.
First and the simplest idea is to compact navigation bar, intro and knowledge bar. The Related column of knowledge bar in this context is redundant as related articles should be listed in navigational bar. Navigational bar should be squeezed as much as possible. TOC should be separate column with fixed size, but not over whole screen, leaving enough room for intro and actual article beginning.
Thanks for your input on this. That said, how should a re-design of the article template work out with the current Reviewing efforts? We promote the use of the Article template (as is) to reviewers right from the beginning and ALL reviewed pages on the English as well as the German Wiki follow that template. Please tell me how you'd like to re-design it without having to do the whole Reviewing again from an template perspective. We have no time for something like this, i.e. we'd have to put the template in question BEFORE starting the Reviewing. But still, if we can adjust the template and it will just work without adjustments to already reviewed pages, OK .. but otherwise .. sorry, this isn't an option as we wouldn't like to throw away work of months. Best, R
Next idea would be to use a method similar to wiki.o.o portals, or template and its documentation, where the main page consists of one or more transcluded pages. This gives possibility to create few views of the same article with very little additional effort. In other words to create modules and then use them in the few articles, or as stand alone units.
How to split article: 1) very short intro in article purpose (problem and offered solution) that can be published (transcluded) in a different content indexes and portals 2) longer intro (Knowledge) that will list mandatory skills and tools to accomplish task (prerequisites) 3) actual procedure or discussion 4) conclusion; what we accomplished and where to proceed 5) article reference index;list of related topics internal and external
This proposal has to be tested with articles about few topics in real setup on a new wiki.
I'm looking for the people that like idea and want to help me with comments, ideas, creation of proposals.
-- Regards Rajko, -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
-- Rupert Horstkötter, open-slx gmbh openSUSE Board Member openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter@opensuse.org Jabber: ruperthorstkoetter@googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
On Tuesday 02 March 2010 08:21:56 Rupert Horstkötter wrote:
... Please tell me how you'd like to re-design it without having to do the whole Reviewing again from an template perspective.
The majority of effort by now wasn't top part that I commented and consider urgent, but fixing, updating and verifying article, for instance that procedure described in article actually works. Once we have clear idea what to do replacing top part with something smaller or placed on right side of the article will be few days work at maximum. Ditto, thinking about and testing different design is not reason to stop fixing articles to comply with current template. It is organized and it should be (near to) trivial to parse it with script and change to something different. The rest of ideas can be developed and applied in a slower pace. IMHO, even if we would have clear idea how to restructure articles right now, applying that during transition will extend transition too much.
We have no time for something like this, i.e. we'd have to put the template in question BEFORE starting the Reviewing.
That is my opinion too, but I can bring up only what I see as a problem and taking how many things we tackled at once it is not easy to find time for everything.
But still, if we can adjust the template and it will just work without adjustments to already reviewed pages, OK .. but otherwise .. sorry, this isn't an option as we wouldn't like to throw away work of months.
See above. Transition to new wiki should introduce new process on openSUSE wiki, article maintenance, in other words each article must have named maintainer, otherwise after some time we will be where we are now. Maintainer duty would be to keep author informed about requirements, best practices, help with example how to use new tools that installed extensions offer, bring up problems that authors find. That means maintainers will have to know guidelines, wiki tools and discuss with other how to solve problems. -- Regards Rajko, -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
Rajko, 2010/3/4 Rajko M. <rmatov101@charter.net>:
On Tuesday 02 March 2010 08:21:56 Rupert Horstkötter wrote:
... Please tell me how you'd like to re-design it without having to do the whole Reviewing again from an template perspective.
The majority of effort by now wasn't top part that I commented and consider urgent, but fixing, updating and verifying article, for instance that procedure described in article actually works.
Once we have clear idea what to do replacing top part with something smaller or placed on right side of the article will be few days work at maximum.
Ditto, thinking about and testing different design is not reason to stop fixing articles to comply with current template. It is organized and it should be (near to) trivial to parse it with script and change to something different.
If it's trivial to parse afterwards, I have no complaints in adopting the article structure again when reviewing has been done. I have strong complaints to come up with a new article template during reviewing as it involves lots of communication with reviewers and adoption of established processes. Anyway not needed if it's easy to parse afterwards. But still, thanks for your general ideas about improving the article presentation.
The rest of ideas can be developed and applied in a slower pace. IMHO, even if we would have clear idea how to restructure articles right now, applying that during transition will extend transition too much.
That's what I say actually +1
We have no time for something like this, i.e. we'd have to put the template in question BEFORE starting the Reviewing.
That is my opinion too, but I can bring up only what I see as a problem and taking how many things we tackled at once it is not easy to find time for everything.
But still, if we can adjust the template and it will just work without adjustments to already reviewed pages, OK .. but otherwise .. sorry, this isn't an option as we wouldn't like to throw away work of months.
See above.
Transition to new wiki should introduce new process on openSUSE wiki, article maintenance, in other words each article must have named maintainer, otherwise after some time we will be where we are now.
While this would be desirable, we won't achieve a named maintainer for every article. Let's keep "realistic" here and let's develop the QA we agreed on to work-around the mess we previously had. looking forward to your involvement here.
Maintainer duty would be to keep author informed about requirements, best practices, help with example how to use new tools that installed extensions offer, bring up problems that authors find. That means maintainers will have to know guidelines, wiki tools and discuss with other how to solve problems.
+1, but see above Best, R
-- Regards Rajko, -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
-- Rupert Horstkötter, open-slx gmbh openSUSE Board Member openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter@opensuse.org Jabber: ruperthorstkoetter@googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org
participants (2)
-
Rajko M. -
Rupert Horstkötter