Loading...
 

WhatYouSeeIsWhatYouCanAccessDev

For new users, the amount of wiki features could be scary, and if many things a user tries gives a "you can't do that" message, the effect will be worse.

The idea is to minimize that kind of message, to ensure that everything the user sees as "clickable" really gives him the opportunity of see or do something.

There are several layers for this:

  1. Don't show what is not enabled system-wide.
  2. Don't show what is unavailable for the user group.
  3. Don't show what the object does not enable the user to access (if my user/group can edit wiki pages, but some page is locked or can't be edited by my user/group, then the edit tab should not be shown; or if the rights of a wiki page, forum, blog, etc don't enable me to see it, then I should not have it listed).
  4. Don't give empty options. (For example, when there are no templates to apply to an edit, should the "apply template" dialog be shown for normal users? The same could have happened with categories if none was created yet, etc)


I think most of the first two points are already done and working, but the last two are not there, and in some cases could be debatable if and when to implement this, and to what extent This also could impact performance, as more calculations and database access must be done, and maybe a lot less could be cached.

Some examples off the top of my head:

If a user can't create pages, and a wiki page has an "unresolved" wikiword, should the the "?" linkk at the right be shown?

Let's see last changes in wiki pages. There are a lot of pages, but, if for each that I will show have to check if my user, group are enabled to see it or the category it belongs maybe a lot more of database access should be done. Also, think in not so highly active sites... if the last movement was last week, should I see the fiirst 4 date range options or should start showing the first page of real results?

Going a bit up. If my user/group can't create i.e. charts, and there is none to list (or worse, none that I could access), should be shown in the main menu?

In the other direction, if I have a mostly empty system, is good or bad to show an almost featureless site? In my opinion, yes. That way, the growing in complexity of the system (always, that from the point of view of normal users) is asociated with the growing of complexity of the content, not just on the amount of options that the admin thought would be nice to have.

I'm not saying that all should be recoded to reach this goal, only that is something in the horizon that could be nice to reach, and if something is implemented looking in that direction, could be benefical in the end.

A not so hard start in that direction is to have functions associated with what is pointed to in menu options and other systems link, with a common suffix like i.e. tiki-galeries-accessable, that in a word, returns "true" when, of course, the feature is enabled, and the user have content for him there. In example, for image galleries, it just need to find at least one gallery that is enabled to be browsed by the current user, or that the user can, within this option, change that doing something, like creating an image gallery. If that functions returns true, then the menu option is listed and enabled. For menu headers that are also actions, first have to check if one of the suboptions is enabled, and then do its own check, if there are internal options visibles but their own check fails, then the menu should be visible but not enabled as link.


Page last modified on Saturday 07 August 2004 15:00:11 GMT-0000

Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting