Forum OpenACS CMS: 2nd meeting and UI group status

I have some more mockups on paper that i will try to rasterise, and I am working through the CR documentation alongside some other CMS docs to build a proper functionality list - i think the first step is for the UI group to discuss and agree on functionality priority (ie. build a complete list and rank from nice-to-have to critical).

That discussion is possibly better done by forum than by meeting.

Then each piece of functionality can have a screen, dialog or screen variation mockup made.

From these mockups, we should be able to define the tcl api required by the pages behind them as well as start work on the pages themselves.

How does that sound for an approach?

Sorry I haven't had the chance to participate in the UI discussions.  I recently uploaded a site which demonstrates our current CMS offering.  (It is an enhanced version of Jun's modetp which was based on the original ETP.)

It can be found at: http://209.10.210.53/ (login/password: mailto:webmaster@infiniteinfo.com / demo).  Here are some relevant points:

* After logging in, click on "Edit This Page" to edit the home page.

* If you're running IE5+, you can use the WYSIWYG editor (IE DHTML control) to edit the page, upload images, create tables, etc.  (Sorry Malte!  I will respond to your post soon!)

* You can also click on "Edit This Section" to see a tree-like view of the site, where you can add/edit/delete/move/copy sections, files, links, as well as change the sort order of the elements and the section template. (http://209.10.210.53/home/modetp-itemlist)

* The site navigation is dynamically generated based on the ETP tree.  And for each element, you can decide whether it should appear in the navigation.  You can also set the "Publish" and "Expiration" dates for the content (currently turned off for this site).

* Non-ETP applications (such as News) are linked in via external links.  This is so that they can still appear in the navigation tree and be easily moved to any section.

* Our clients have used this CMS to create sites like www.vipcolor.com and www.simiwinery.com and have generally been quite happy with it.  Unfortunately, the code behind it is a bit of a mess and not in a release-able form.

I'm not suggesting that this be the final UI for our CMS product.  Not at all.  But I do think a few good ideas can be lifted from it.

Feel free to experiment with the demo site to your heart's content (pun intended)!

Great work with your UI mockups Mark, very clean!

There is another UI approach I think we should also investigate.  It is not incompatible with your approach and in fact could nicely complement it.

The concept comes from a demonstration I saw of IBuySpy Portal and shares some of the best ideas from dotLRN's portal manager, ETP, and even our current sitemap.

From what I recall, site admins could manage pages as well as mount various modules through a standard "tree" interface.  When editing a page, you could add and edit portlets anywhere on the page.  A portlet might, say, show site visitors the last 5 news items or top 10 discounted products.  You could also add content anywhere on the page in a similar manner.

The demo planted the idea in my mind that an ideal CMS is more than a simple content management system, but rather a site management system.  I'm not suggesting we build this for the first phase, but that this could be a guiding vision.

Here's some URLs relating to IBuyPortal:

http://www.cebware.de/download/programs/mobilewebportal/index.htm (the only screenshots I could find, in German)

http://www.asp.net/Default.aspx?tabindex=5&tabid=42

That might be a v2 feature, but some time in the future it could even totally replace the sitemap interface and make the whole site run by cms mounted at root (thus eliminating the hoops you have to jump through to make the homepage an etp page).

Oh, and Tuesday sounds fine to me.

Oh (2), Robert a clickthrough demo is a great idea, but i think building that could be done at the same time as the api is starting to be written to save time (since once the core features are decided, tweaking the ui shouldn't change the core functionality requirements too much.

We do want to build a nicer user interface over site-map, i think Lars is working on this with the acs-subsite admin pages rewrite.

I was looking at it from the other way around, in that the CMS could add pages to any site-node, and eventually would be able to supply replacement adp templates for any adp in the system. This seems liek a better way to integrate with existing OpenACS functionality.

Lets do something something simple and nice.  I guess I leave it to the UI group, just my opinion.

"I guess I leave it to the UI group, just my opinion." - that would be me ;)

Regarding the different mount strategies - if you take a look at my function list (here) one of the ways i describe allows for cms bits to be mounted anywhere, all part of the main cms. Unfortunately that leaves our CR tree not matching the actual website tree - whereas mounting packages inside our cms tree means the cms tree exactly matches the website tree.

While I prefer the latter, I don't think it's achievable in the short term (technically, or in terms of getting everyone to agree).

The site-node problem is easy.

Any CMS will have a seperate cr_folder tree. Give every site-node a cr_folder in this tree. This way you could add a page under forums for example, and it could be managed by the CMS. Eventually I want to be able to define ADPs through this CMS interface to override built in templates.

On tags for including content. See the original CMS. I am pretty sure it already includes this feature. It defines several of its own tags. Basically something like <image name="foo"> should work, if something is in the same folder, otherwise you would use an abosolute url <image name="/images/foo'>

Evenrually we will want a way to manage uploaded files, and this system could include a way to choose an image or binary file, and insert a link into the page content.

We would need to register some way to maintaint he cr folders based on the site map.

You should look into the original CMS package. It has some very good ideas, maybe not full realized, but it addressed most of the issues in some way.

My ultimate goal is to allow rendering on an ADP combined with content to the filesystem. We have already discussed having a package instance specific customization location. The CMS can output ADPs to this location, so the request processor just looks in this directory. I belive the request processor remembers the file-URL mapping if you have PerformanceModeP set to true, so this shouldn't be a huge performance hit. There is probably  a way to clear the cahche if the file for a URL is changed.

I like the lists of templates and content items, tasks, etc. I think that style will work well. I like the tabs across the top for different things, templates, cotnent items, tasks, etc much better than the tree view of the original CMS.

There are some screenshots and info on Typo3 GUI/functionality that look pretty nice as far as UI goes (haven't used Typo3 myself).