Re: Default Template discussion

Murray suggests:
>I'd also make sure that if there is a top and bottom set of tabs
>or buttons, that they be the same set on top *and* bottom.

I agree

Dirks ideas:
>TABS section will be used for the key Page related actions
>User section above the HEADER block. (right aligned)

I agree with the choice of items for each section and their respective
placements

Janne's comments.
I agree with all of them except I'd leave comment as Dirk suggests or see
new suggestion below.

Janne>If there was a way to make it constant, I think that would be
>better.

I couldn't agree more with this. But that requires a rethink of the entire
problem, doesn't it?
In this case a dedicated right aligned pageactions block wouldn't be needed
would it?

I am starting to *see* that *my* problem was that I was not getting the
motivation behind doing it the way its done today. You will have this
problem with others as well I pressume. Views can change and you can get the
aha reaction later. However, with that said, I still believe that the best
designs dont need to be explained to a user. Quality can be difficult to
describe but it is recognized immediately when encountered. With UI
simplicity and ease of use rules.

>The 'page-actions' block (next to the tabs, but right aligned) will be
>configurable through a new Wiki Page:  'Navigation'. (I will propose a
>format later)
>An Admin can use this (pageactions block) for often used and very important
links

OK so now we have an Admin configurable:

left Favorites block.
right aligned pageactions block

If the tabs could be fixed then the left and right menu  blocks could be
left to the discretion of the Admin. He can place them where he wants and
puts what he wants in there.

New Suggestion for Comment and Attach:
1. Group all edit changes allowed to a page in one place (ex. under the Edit
Page Tab):

Add Comment
Add Attachment

It should be perfectly clear to  users which users can:
upload an attach, edit and comment tab page, rename etc..

Visibility:
When a  tab is there the user expects to be allowed to do something with it.
If its not there, he will use a lot of time wondering why its missing. Its
good that in 2.5 you have a statement as to who is allowed to do what.

Take attachments:
In Alex's 4.5 online example, I was allowed to upload a file as an
attachment before
I was informed that I am not allowed to perform this operation--Not cool--

In 2.4, there was no indication that I had to be authorized to add an
attachment nor was it clear that only an admin could delete an attachment.

Dirk I am just wondering, if the tabs could remain as you described could
it make sense to have a menu block within the content page. Each link or
button would pertain to the tab page.

In this scenario, the page I am editing either has an comment(add/cancel
comment buttons) and has an attachment(add/delete buttons) ..

Perhaps some prototypes are in order??? :-)








On 7/19/07, Janne Jalkanen <[email protected]> wrote:
>
> > TABS will be used for the key Page related actions:
> > * View
> > * Edit
> > * Attach (#) :get list of attachments, add attachments, preview
> > attachments
> > * Info : get version history of the page, rename a page, delete a page
> > * Link (only visible when Info is active) : show all incoming and
> > outgoing links of a page
> > * Diff : Show difference between 2 page versions.
> > * Comment
>
> What bugs me with this is that the tabs change according to the
> view.   This is not exactly "path of least surprise". In addition
> when you are watching a list of attachments, depending on your *real*
> URL the tab list is different.  I know the technical reason why that
> happens, but to the user it can be a bit of a surprise.
>
> If there was a way to make it constant, I think that would be
> better.  Somehow when you click on a tab in Windows, you don't expect
> the other tabs to change.   I would rather use nested tabs for e.g.
> PageInfo.
>
> I would also keep "comment" as a separate button.
>
> > Some remaining links in the More... menu of today:
> > * System Info: ... ?
>
> Not really useful, I think.  I mean, the geeky people like to look at
> SystemInfo, but I don't think it's that useful for anyone else.
>
> > * Workflow  :  suggest to bring this under UserPreferences as it
> > really is about your contribution in certain workflows (at least that
> > is my understanding of it)
>
> Yes and no.  It's not a preference.  So I don't know how many users
> would look for it there.
>
> /Janne
> _______________________________________________
> This is the Jspwiki-users mailing list, in which we discuss the
> stable release (even-numbered, 2.4.x, 2.6.x), and user-issues.
> For development discussion, please join jspwiki-dev.
> http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
> http://www.jspwiki.org/JSPWikiMailingList
>