Forum OpenACS CMS: 2nd meeting and UI group status
How is the UI group doing? Since the main agenda on the 2nd meeting will be the UI. Is it too soon for this week's thursday? Jul 24? Or we move it last week of July?
Main agenda will be UI on the 2nd meeting. Whatever the UI group will discuss we will pick up discussion from there.
BTW all meeting should be 1 hour or so only. So when would we meet on the 2nd meeting this week or next week?
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?
Also, I have posted up a chunk of links of varying interest at:
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.)
* 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://22.214.171.124/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)!
I think Mark's approach is good. This is similar approach I did to create bcms for a client.
I think we should just meet next Tuesday Jul 29 10:00 am (GMT-4). Can people confirm that they can make it? Main agenda will the UI. But as Mark has said the UI team should hold some discussion in the forums. Can someone lead this?
Since we are replacing the aD CMS. I think we should cover all of its functionality. Although may some none CMS related stuff that is already being done by other packages must be left out. Such as user management.
Nice to see that modETP is still in use.
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)
On a related note, has anyone heard of Rainbow Portal? Seems interesting.
From the home page:
The Rainbow project is an open source initiative to build a comprehensive content management system using Microsoft's ASP.NET and C# technology. A VB version is also available.
Rainbow, available today in 14 languages, allows content authoring to be safely delegated to role-based team members who need little or no knowlege of HTML. Rainbow optionally supports a two-step approval-publish process. 45 plug-in modules are now included in the standard release, including support for an e-store, XML news feeds, Flash, Maps, Newsletter, Surveys, Forums, Document Management, Custom Lists, and more. It's also fairly easy to build your own custom modules using the guidelines provided on the Developer's Info page.
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.
i think a measure of success is how SIMPLE we can make it while still achieving the aims of 95% of users. The remaining 5% will always be paying for customisation anyway.
The aD cms feels a lot like it's trying to be a 101% solution, and alienates normal people in the process (as well as making for an unweildy code base).
I would like to see a more bug-tracker like level of complexity.
I'm going to bed and taking a bunch of printouts with me to finish this feature list, which I will start a new thread to discuss.
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 latter is similar to etp. Basically each etp instance is a package instance, so it has site node. It also creates a cr folder.
The former I think is how aD cms does it. CR folders is out of synch.
I think this is a good topic to discuss in the IRC meeting. Which way to go.
The advantage of synch site node and cr folder is that the CMS will act more like a site. The disadvantage is that its less flexible. So if the cms is less site centric, say displays items on a category basis. Or maybe content is displayed in more than 1 way. So in sync fits more for simpler cms, while out of sync fits more in bigger cms.
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.
"Give every site-node a cr_folder in this tree." - You mean every site node in the whole openacs site, even ones not nominally under cms control? How would this be kept up to date?
"This way you could add a page under forums for example, and it could be managed by the CMS." - it seems to me that that would require modifying (and slowing) the openacs request processor, since it would have to check for valid cms pages everywhere - or at least as a default failover (actually not such a bad idea... but still a pretty radical change).
regarding Robert's idea about portals, rather than a UI, i think we just allow designers to do something like <include name="top-news" count-value="10">. This would include tcl/adp pairs from initially a folder in cms, but ultimately should be db based as well.
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.
A mockup based on the discussion so far, the acs-subsite work Lars did and some old CMS pages -
(there are a lot of goodies in the existing CMS package)
A major thing that is still missing from the mockup is the ETP interface. The path to that would be the "Edit" link on the index CMS page:
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.
But what the ui contains depends on the discussion of the task list, since your homepage view, for example, depends on how we do publishing - is it a workflow, etc...
Same with the etp page - it depends a lot on our discussion of how & when revisions get made, pages go live, etc.
So my view is we need to nail down the feature list and a few of these details, then we go hard making a clickthrough mockup.
Also, we need to agree on the overall look & feel - your mockup is a bit more traditional cms, mine a bit of a morph of the best ideas (I think) of a number of cms packages.
We will probably need to get a randomo vote on a "main" page that will drive the rest of our mockup, along with the feature list.
There are some screenshots and info on Typo3 GUI/functionality that look pretty nice as far as UI goes (haven't used Typo3 myself).