Item293: Create a view template for extensions combining doc, talk and support
Priority: Normal
Current State: Closed
Released In: n/a
Target Release:
Applies To: Web Site
Component:
Branches:
Inspired by
ArthurClemens work in the Support web, I created a similiar view template for the extension topics in the Extension web.
Idea is to combine the plugin documentation topic with its (developer) talk page and the corresponding support items. Everything should be done in one place.
Demo
Example: ie.
ChartPlugin
Requirements
- Has to work for
NatSkin and PatternSkin.
- Does not require change of extension topics.
Implementation
Extension topics are identified by their attached form (preferebly via
AutoViewTemplatePlugin). The view template is wrapped around the whiteboard text. The original TEXT (plugin doco content) goes into the first tab. The second tab (Download) is filled with the attachment table. Finally the third tab holds the support infos:
SEARCH on Support items plus link to create a new support item plus link to the developer topic. The last tab contains the corresponding tasks.
http://test.foswiki.org/Extensions/PackageViewTemplate
Known bugs
- Hitting the "closed items" button on the tasks tab correctly reloads the page but opens the (default) tab and not the tasks tab.
- Download tab: wbnif the attachment table wasn't in a (closed) twisty container.
Todos
- install AutoViewTemplatePlugin on this site
- add conditional code to handle non-existing Developer topics
- make it look nicer
Help needed for (3).
--
OliverKrueger - 24 Nov 2008
Looks like a good solution.
By using the same PLUGINTOPICDev name (ie Dev at the end) for the talk page - we can bring in the 500 Dev topics from t.o. and not loose the content which is very important.
For the default plugins we should clean out these Dev pages but it is not realistic that we do that with all 500.
Make sure that the Dev tab can also show attachments. There are many attachments with patches in the Dev topics that I do not want to loose. I have applied one as late as one week ago in a plugin. These are worth gold and must not be lost.
Also the Dev links from the local installed Plugin topic must still lead to a sensible result.
Appraisal topics we discard. They are worthless.
--
KennethLavrsen - 17 Dec 2008
a very topic template would be even spiffier than what we recently made with the extensions hub et al. what is the current thinking on what to do with this?
--
WillNorris - 11 Apr 2009
http://foswiki.org/System/AutoViewTemplatePlugin installed on foswiki.org
--
WillNorris - 01 Jun 2009
Second try...:
TestTopic44514 (with
TestViewTemplateDisabled)
--
OliverKrueger - 23 Mar 2010
also deployed in the Extensions testing web!
eg, at
Extensions.Testing.FortunePlugin
--
WillNorris - 23 Mar 2010
I like it. Except, should "Development" not be a part of Support? or should it be "Discussion"?
Could we bring this even further, by having additional tabs for:
- "Introduction" - what this is about, for whom the extension is intended, and a small and simple example
- "Macro syntax" with extended examples
- "Complete documentation" on one page for reference and printout
Download should include the dependencies and installation instructions.
--
ArthurClemens - 23 Mar 2010
those would be good changes, along with twisties on the history; unfortunately, i don't see how to accomplish these things without the whole of the extension topic's format itself being given a (badly needed) makeover*, but i don't think we perform that within the scope of this task.
it would be nice to have icons on the tabs, but i didn't see how to do that.
would like to see the button for closed/fixed bugs in the development tab as well.
the "introduction" tab (demo?) would be a good place to put a screencast, i think.
* (well, i suppose some clever dhtml could actually accomplish most of those things)
--
WillNorris - 23 Mar 2010
Could this be done using sections? For instance using
STARTSECTION{"intro"}...ENDSECTION{"intro"}
. And then render it using
TAB{"Introduction" section="intro"}
(not sure how TAB is supposed to work, but I would expect a differentiation between label and id.
Using sections would make the topic format implementation neutral: it is not formatted specifically for tabs.
--
ArthurClemens - 23 Mar 2010
Feedback from
MichaelDaum:
- tab interfaces are no good user interface for navigating to different pages. better would be to use the sidebar navigation or a TOC-like table to jump back and forth.
- basically, the tabpane doesn't serve well as a user interface in this case. there are better ways to integrate these pages.
- a simple navigation list is all fine <ul <li page 1 </li> <li class="current">page </li> <li> page 2 ... </ul>
- even better: list real actions what the user might do next: see all open bugs, file a new bug, ask a support question, leave a comment.
- download latest stable, download experimental release
- see screenshot gallery (if applicable), contact author, ...
--
OliverKrueger - 02 May 2011
Removed without further discussion.
Closing.
--
OliverKrueger - 04 May 2011
Tabs or no tabs, it depends on the situation. Below are 2 sites that sell books: Bol.com and Managementboek.nl. The first site uses tabs. I have been involved in the redesign of Managementboek.nl and we have decided to not use tabs for the new design.
Our reasoning has been that tabs work well for relatively short content and known items - if you are looking for user reviews you may look for the tab. But tabs are less suited for browsing and content that you do not expect.
What happens if you have scrolled down the content (reading or skimming) in those 2 cases? With tabs you have reached the end, and only if you know what you are missing you will be inclined to scroll up to view the contents of the other tabs. Without tabs (using sections) you simply read/skim on to the next section.
To facilitate known item browsing we have included a stick nav bar with a fold out menu
Example of bol.com (Dutch) that uses tabs:
Example of Managementboek.nl (Dutch) that uses sections:
Example of Managementboek.nl (scrolled down):
In our case it probably makes more sense to keep separate pages and to facilitate browsing to the pages. Either with a side menu or top menu. Michael's suggestion to include actions is fine.
--
ArthurClemens - 04 May 2011
Stalled. Closing.
--
OliverKrueger - 16 Dec 2011