Re: Default Template discussion

Alex,

Tx for the screenshot ! I really like to see  IE screenshots ;-D

However, a new problem I see is the top-of-screen display of My-Prefs,
Login, and the username.
Is this present in all screens ?

For the combination of commentbox and tabs, most of the issues should
be resolved by now.
I notice on your website that you still have a problem when
commentboxed-images don't fit inside the tab.

You now you can 'hack' such a page by inserting at the end of that tab
some extra  '%%(clear:both)' markup, like this:

%%tabbedSection
%%tab-Tab1

%%commentbox
some large image here
/%

Your tab text

%%(clear:both;)
/%
/%
/%

I need to think of a solution for this. Can you log this on the bugzilla plse.

dirk


On 7/25/07, Alex Samad <[email protected]> wrote:
> I tried very hard to remember to attach the picture, 2nd go
>
>
> On Wed, Jul 25, 2007 at 08:54:36AM +1000, Alex Samad wrote:
> > Hi
> >
> >
> > I have attached a screen capture of 2.5.107-cvs (sorry best way to describe is
> > with pictures)
> >
> > you can see all the stuff in the top right hand side is all bunched up wrongly
> > - looks messy.
> >
> > I think My Prefs should stay on the right maybe in line with main/more.  But I
> > definitely liked G'Day <User> on the left under the symbol - login/register not
> > sure.
> >
> > But it would also be nice to have a flag to change all the login/register to
> > just login.  I don't want people to register via the wiki - I have my users in
> > ldap, it would be nice to be able to easily hide/remove the register bits, but
> > it seems like every where there is a login there is an option to register as
> > well.
> >
> >
> > Alex
> >
> >
> > On Fri, Jul 20, 2007 at 10:52:07PM +0200, Dirk Frederickx wrote:
> > > Hi Claudia,
> > >
> > > Tx for your inputs.
> > >
> > >> 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
> > > Still, with CSS skinning, you can place the User section anywhere your
> > > want.
> > >
> > >
> > >> In this case a dedicated right aligned pageactions block wouldn't be
> > >> needed
> > >> would it?
> > > Yep. Actually, the 'pageactions' at the right side are really getting
> > > reduced to
> > > a
> > >
> > >>
> > >> 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
> > >> >
> > >> _______________________________________________
> > >> 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
> > >>
> > > _______________________________________________
> > > 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
> > >
>
>
>
> _______________________________________________
> 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
>
>