Feature Requests for OpenACS.org's XoWiki

Created by Robert Taylor, last modified by Gustaf Neumann 19 Oct 2017, at 08:51 AM

Overview: 

Most of the Feature Request are complete.  THANK YOU GUSTAF AND DAVE! I am adding a few minor enhancement requests and removing the completed requests.

Participants:

Some comments to the requests from Gustaf Neumann

Comments and responses by Robert Taylor

Feature Requests:

1.  DELETING DOCUMENTS - Normal users should not have DELETE privileges, but administrators should.  As an administrator I don't see a DELETE option in the menu in the top right hand of ever page.  Perhaps DELETE should go between NEW PAGE and INDEX items.

    Added delete button on the view page. mostly useful, when the default listing of all entries is replaced by a tailored index page
 

2.  HIERARCHICAL CATEGORIES - Left hand menu needs to properly show SUBCATEGORY WITHING SUBCATEGORY in a hierarchical relationship.  Clearly one thing we will have to take into consideration is hierarchy layout and spacing issues - do we preload all categories or do we just preload a preset number of levels down and then dynamically load the rest below a certain threshold. Dave mentioned the ui component has to be coded up to handle that type of layout.

     Hierarchical display of categories added to the version in CVS head. Spacing is a matter of style-sheets.  

3.  XINHA SUPERPOWERS - Xinha is one amazing editor, and just looking at their page it's still  not complete.  I think we need to look at stripping some of the features out of our Xinha install on XoWiki.  This should probably be based around generating a STYLE GUIDE for the wiki and basing our Xinha hacking on that.  Dave mentioned it is possible to take away Xinha features fairly easily so we will look at that further.

 xinha is configured via plugins (see http://xinha.gogo.co.nz/xinha-nightly/examples/full_example.html). xowiki uses per default the following settings, which are some standard options plus the OacsFs plugin contributed by Günter Ernst and me.  The standard behavior  can be modified by the settings of the WikiForm (in xowiki-procs) for the whole installation. a per-instance setting will follow in the future

4.  ADMINISTRATION SECTION - If you select the "WOIKI" item in the location area on the page (OpenACS Home : xowiki : New XoWiki Page) the link seems to alternate between the INDEX page and ADMIN page although it seems a bit random.  I think this is probably a bug, but it should be changed to the following:

a) Selecting XOWIKI in the location of the page should always go to INDEX just like the item "INDEX" the the wiki page UI does. 

b) For administrator we should add and item ADMIN to the wiki page admin menu so that the administrator can go to the admin section and work on templates, delete documents, etc.

 can't reproduce a. xowiki in the breadcrums and index both point to oacs.orig/xowiki, so they should return same values. in earlier versions  there was a caching bug, which is - i think - gone since end of Feb.

concerning permissions etc. currently, xowiki uses a simple permission system: it checks write permissions on the folder, these write permissions are used distinguishing admins and readers. future versions should have a much richer permission system, where one can use alternatively different permissions policies based on per page permissions (this is however, much more expensive and will use much less caching). for now, do you folks want in addition to the new delete entry also an admin button in case a user has write permissions on the folder?

5.  PRINT PAGE - All users should have an item in the wiki page menu (for every wiki page) labeled "PRINT".  This action would refresh the page content and / or bring up a popup with the content of the page in a printer friendly format without various user interface components.

6.  IMPORT / EXPORT DIR TREE - The ability to import/export a directory tree of XoWiki documents has use for OpenACS.org and arguably as a general XoWiki feature. In the case of OpenACS, exporting would allow these /xowiki pages to be saved into static pages so that they can be read independently of OpenACS.org and independent of having a local running OpenACS system.

Problem example: OpenACS moves documentation to XoWiki. Documentation is no-longer available as static pages on local machine(s). Users/admins become dependent on reading docs from OpenACS.org or spidering the pages using wget etc.. of course most likely during the busiest times that OpenACS is being accessed ;) etc. etc.

7.  PAGE REVISION (AS TIMESTAMP) - Exporting files (request 6) would bring about questions of comparing file exports (at least on a page by page basis). Having a page revision displayed on each page as a timestamp would help to reduce any ambiguity as to which statically exported page is more current --regardless of export technique (wget, XoWiki export feature etc.)

 

 

Bugs

• xowiki is not visible in IE. Must be a CSS issue. Has someone an idea why this happens?
  • no kidding?!  doesn't work in i.e. will post bug
  • fixed. this was an unclosed script tag in the  xowiki installation on opeancs.org
• For some reason I always get a popup window: "Error reading Language-File (/resources/acs-templating/xinha-nightly/plugins/OacsFs/lang/de.js) - Syntax Error: missing ; before statement"
  • must be something on oacs.org, does not show-up on other installations. i have developed the plugin, and do not have the mentioned file.
• The CodeMatrix includes need a little clean up: left alignment and top valignment for each heading
  • must be done by someone at oacs.org or vinod. most probable some CSS fiddling.

Display

• Page language: Wouldn't it be more readable and less technical if we would not display the language shortcut "en:" or other before each link to a wiki page?
  • one can use arbitrary labels in a reference between square brackets.
• The category tree on the left breaks long names which is ok but the next line should have more left margins in order to start right after the dot. Another solution would be to cut off the tail of long names
  • CSS fiddling. should be done by someone with CSS knowledge and  taste. uses currently the original settings  https://openacs.org/resources/acs-templating/mktree.css from http://www.mattkruse.com/javascript/mktree/documentation.html|mktree

Further Features

• support for NOTIFICATIONS for xowiki so that you are notified if a page was added or changed
• List view for category nodes that displays all children on the right when you click on it.
  • don't understand. you mean, without expanding the current page?
• Display the name of the person who edited the page in "Latest Page edits (ADP portlets/categories-recent {name {Recent Entries by Categories} max_entries 30)

Packages

• Any chance that we ca define a sub type PackagePage that automatically provides the info, bug-tracker and code metric includes?
• Some kind of traffic lights that shows green, yellow or red depending on the maturity of the package, db support
• More categorization for packages: Core, Non-Core is too technical, no?
• When clicking on a category it would be great if the list of all packages within the category are displayed as APM does on upgrade/installation time.
  • sounds like a different or additional category tree

 

Most Popular Pages

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:15 AM

Activity Graph

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:12 AM

XoWiki: List of the available includelets

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:11 AM

This is a list of the includelets, which can be included in a xowiki page: 

XoWiki: How to save files directly in the wiki

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:08 AM

In order to save files directly in the wiki, just add a link with the content file:yourfile to a page (as for other links, between curly double brackets).

[[file:oacs-dotlrn-vienna-xowiki.pdf|XoWiki Slides from the Vienna OpenACS conference]]

When the file link is added, and the file does not exist, the wiki marks the link with a handle to upload the file. According to the current policies, everybody who is logged-in has sufficient permissions is allowed to edit pages.. 

Here is an example of a file-link, pointing to the xowiki slides from the the Vienna oacs-dotlrn conference XoWiki Slides from the Vienna OpenACS conference

 

Directory of OpenACS Sites

Created by Caroline Meeks, last modified by Gustaf Neumann 18 Jun 2017, at 12:59 PM

Big Picture

The "Community" section of the OpenACS website still uses Edit This Page and has not been updated in years.  This proposal is to begin the work of updating it by replacing: https://openacs.org/community/sites/ an Edit This Page application, with a new package.  This package is expected to be an incremental improvement over the current page, and the current vision, and certainly the first iteration will not provide everything we might ever want to know about how OpenACS is being used.

To attract new developers we need to effectively communicate all the possibilities that can be created using OpenACS. One way to do this is to more effectively highlight existing sites.

You can add you comments to this page or the forum thread https://openacs.org/forums/message-view?message%5fid=605925

User Stories 

User Stories are a method of defining requirements by creating fictional users who might use the feature.

Mary - Developer considering OpenACS

 (see en:docs-eng part of en:openacs-handbook with document guidelines shaped by these requirements: en:docs-eng-reqs -Torben)

Sam - A developer who has just launched an OpenACS website

George - A current OpenACS developer who wants to see a package that he has never used in action on some existing sites 

 Who

This is a joint project between Solution Grove and Miguel Cordova of UNED.

Why

Goals include:

• This package is primarily a new UI for the existing functionality.
• Improving the OpenACS Community and outreach to new developers.
• Solution Grove is using this project as a means to give back more of our AJAX and Dynamic types experience the community.
• Miguel Cordova is using the project to learn more about AJAX and OpenACS and he will work with his group at UNED to bring what he learns into dotLRN.
• This package will provide a place on OpenACS.org where people who are evaluating OpenACS can see that AJAX can be used with OpenACS without changing the user experience for current frequent openacs.org users.
• This package may be useful during sales for OpenACS vendors, including Solution Grove, to demonstrate the capabilities of our platform.
• This package is an incremental improvement on the current Edit This Page page.  The goal is not to provide a complete solution to our desire to understand how users are using OpenACS.  However, the design should allow integration with any automated APM based solution that might be developed in the future.

The Plan

Step 1 - Use Dynamic types

Use dynamic-types and categories to create a data structure to collect metadata about OpenACS sites.  For details see Data entry screens.

Step 2 - Data Entry UI

Use an AJAX tabbed UI to collect the data

Tab 1 - Basic Information

• Site Name - required
• Description - required
• site url
• case study or video url
• Type of site - Category list, allow multiple selections
  • Intranet
  • Extranet
  • Eccomerce
  • eLearning
  • Knowledge management
  • Content Management
• Type of Organization - Category
  • Corporate
  • Nonprofit
  • Education Sector
  • Individual
• Organization Location (someday we might do a google maps mashup for fun)
  • City
  • State
  • Country

Tab 2 - Technical Details

• What functionality does this site provide - Category
  • Forums
  • FAQ
  • Chat
  • File storage
  • Bookmarks
  • Wiki
  • etc. we don't want to go quite down to the package level (eg we want forums not dotlrn-forums, forums, forums-applet)
• If possible please provide direct links and descriptions to any interesting implementations of the above or custom functionality. Please indicate if your link is a good example of "out of the box" OpenACS functionality or customization. Both are useful. If your site requires login its great if you can provide a guest account or give an email where users can email if they would like access.
  • XINHA text input. I think we keep it simple here.
• Companies that work on this site
  • Category list populated from our company list
  • Also "In House"
  • "Independent Contractor"
• Languages used
• What version of OpenACS kernel are you running? - Category list
• When did you start development? - Date widget

Tab 3 - Additional Details

• Please use the form below to enter any additional details that other people might find interesting. You can use the image button to upload screenshots. Thank you!
  • XINHA text area
  • Take into account accessibility (e.g. Accessible Rich Internet Applications (WAI-ARIA) Suite concerning accessibility of "Web2.0" technologies including AJAX and the Ajax accessibility examples.

Data Entry 

Just as with the current Edit this Page Information will be entered voluntarily by site developers and owners who are  proud of their sites and wish to give back to the OpenACS community.  Only the most basic information will be required fields, everything else will be optional. 

The user who creates the entry should be able to edit it. In addition users with SWA will be able to edit information.  Undoubtedly information and links will get stale as they have in the current Edit This Page version.  The package should allow granting admin to a volunteer who could maintain information.

Search UI

The search UI should show off progressive enhancement. Functionality should include

 Filters based on categories

Tag cloud of the categories and full text search (example: library/search-categories)

Results grid with title, description, url, and other information. The url should have an image of the url when you mouse over it (look at a specific tag on 3ecompass.info and mouse over url for an example).

One Web Site Detail Page

We will also need a page for each entry where we attractively display all the information about the site.

When we list categories on this page (e.g. what features are used) these categories should be links and clicking on the link should take you back to the search interface with all other sites that have that category shown. 

Notes

• This package is designed to be an AJAX showcase and make almost gratuitous use of AJAX.
• The use of categories and dynamic types makes it easy to change pick options and data collected so we don't need to think too hard about these choices before we start.

More Bells and Whistles

 This is a brainstorming section, not all these ideas will be implemented

• Notifications when a new site is added
• Ratings with an AJAX drag your mouse over the stars interface
• Views
• "Hot Sites" include for the front page
• Random featured site include for the front page.
• Google map mashup with location and/or reverse lookup of IP
• Mashup with something like Delicious, where we look up how often and with what tags the site has been bookmarked.
• Integrate with RSS feeds from user tracking currently under development at UNED

Examples and Links

We are using YUI-ext. An example of what the panel UI looks like.
http://www.yui-ext.com/deploy/yui-ext/examples/layout/complex.html

Tabs can be implemented in the panel interface. Tabs can also be implemented independently from the panel UI. Below is an example :
http://tech.contextsensitivesolutions.org/register/user-new

Scope Limitations

The proposed project is designed to replace one, out of date Edit This Page page.  The first iteration should be designed and developed with future features in mind but, by necessity it will not include all desired possibilities, nor will it solve all potential issues.

• No changes to OpenACS core nor to any package that is included in dotLRN are currently anticipated.
• It is not anticipated that many other OpenACS sites would want to use this exact package on their sites. The source code will be made available if people want to browse it.
• This area will not be a very good demonstration area for Dynamic Types because we be exposing the web interface to change the dynamic types except to admin.  Creating a demonstration area for Dynamic Types is a good idea but a separate project. People interested in this might want to explore dotcommunity.org and talk with the folks at XArgs, its pretty cool stuff.
• This proposal is not a beach head to put AJAX throughout Openacs.org, indeed it is intentionally putting AJAX demonstrations into a corner of the site that is not often used by day-to-day users  and into an area where we highlight the diversity of uses of OpenACS. It is a goal to continue to document how AJAX can be used in OpenACS.
• Integration with contacts and replacing the company listing with contacts is not in scope of the first iteration but should be considered during development and anticipated in future iterations.
• Automated connections to other sites is not included in the first iteration, however it is definitely something that should be considered during development and anticipated in future iterations.
• Accessibility - Olga's points are noted and thoughtful discussion of this issue is in process
• Maintainability -  Just as with the page it is replacing there will be maintenance issues. This is an area of the OpenACS where we gather information from humans who have developed OpenACS sites. Gathering information automatically is also a good idea, but it should be in addition to, not replace asking humans directly to describe their sites and to get insight into things like what makes this site cool, what is the purpose of this site, etc. Anything entered by humans will get stale and will need maintenance by admin. We can improve on the current version by displaying fresh sites near the top. Further mitigation ideas include a link for visitors to report out of date info or dead links, and/or automated link checking.