Hi Caty, On Thu, Oct 24, 2013 at 11:34 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
> I'm reviving this thread in order to make some notes. > > I really think we should reach a conclusion regarding this point since we > have an increasing number of pages that IMO should not display the > #docextra. This is because XWiki is now targeting more applications usage > than just simple pages. Maybe a simpler solution would be instead of > marking what pages are 'applications/technical' pages, just mark what pages > contain 'content' (and thus need a way for people to comment on them). > > On Wed, Jan 23, 2013 at 4:54 PM, Vincent Massol <[email protected]> > wrote: > > > Hi, > > > > For the record here's my POV: > > > > * For technical pages that are meant to be seen by users (thus pages that > > are not hidden by default), such as Main.Tags, I think we could do 3 > things: > > ** set Page Access Rights on them so that they are not editable by non > > admin users > > ** setting #set ($displayDocExtra = false) and doing this should also > > remove the links at the top since otherwise it's not very logical (if we > > keep them it's the same as saying that bottom tabs are not good anyway > and > > should be removed - which is possibly not something bad to do but > probably > > goes beyond this proposal) > > > > Regarding the removal of the links I kind of disagree since they could be > considered like shortcuts to the functionality. The only difference would > be that instead of linking to '#comments, #attachments, ...' they could > always link to '?viewer=comments, ?viewer=attachments, ...'. While comments > are needed just for 'content' pages, 'attachments' and 'history' have a > more generic usage. > This looks like a good idea. Another improvement could be to allow access to attachments and history > also from the 'edit' mode. This would fix some of our functionality access > problems. > I agree that now that we have drag&drop of attachments (with no page refresh needed) we could add the attachments tab in edit mode. Another idea would be integrate the viewers shortcuts in the 'More actions' > menu while removing them from #docextra, but this solution should target > our new skin. > > > ** I think that #set ($displayDocExtra = false) should be set *only* if > > the user doesn't have edit rights on the page, so that users with edit > > rights can add attachments, view page information, etc. > > > > * For purely code page (ie pages which are hidden by default), simple > > users are not supposed to view them and thus it doesn't really matter if > > the docextra tabs are displayed or not. However for consistency, I'd > > propose to have the same strategy as for technical pages meant to be seen > > by users. > > > > * I know of one exception: The home page. It's a technical page meant to > > be viewed by end users but it's also meant to be edited by end users. > Thus > > for that page I would consider it as a normal content page. > > > > Is that compatible with what has been said so far? > > > > Thanks > > -Vincent > > > > Another related use case are the 'creation' pages: for example > 'AppWithinMinutes.CreateApplication' or > 'WorkspaceManager.CreateNewWorkspace'. For the last one we also have this > issue http://jira.xwiki.org/browse/XWIKI-9365 that needs to be fixed very > soon. In this case, in order to assure consistency with the other Create > Steps (Create Page, Space) we will need not just to remove the #docextra, > but also maybe some improvements on the title elements. One idea was to > create a new action (especially for the 'New Wiki' step), but the thing is > that we still don't have a rule regarding the 'creation steps' and all our > installed applications will need the ability to add 'application pages'. > I agree that #docextra is not needed on these pages either. Guillaume In order to assure consistency and not to have cluttered/unneeded > functionality we need to make up some kind of rule and a mechanism to > simply apply it (setting access rights for so many pages seems to be kind > of complicated and maybe we can find a more simple solution). > > Thanks, > Caty > > > > > > On Jan 23, 2013, at 7:20 AM, Sergiu Dumitriu <[email protected]> wrote: > > > > > On 01/20/2013 02:48 PM, Vincent Massol wrote: > > >> > > >> On Jan 20, 2013, at 6:54 PM, Sergiu Dumitriu <[email protected]> > wrote: > > >> > > >>> On 01/20/2013 11:31 AM, Vincent Massol wrote: > > >>>> > > >>>> On Jan 20, 2013, at 5:22 PM, Sergiu Dumitriu <[email protected]> > > wrote: > > >>>> > > >>>>> Hi devs, > > >>>>> > > >>>>> For content pages, the bottom tabs (comments, attachments, history, > > >>>>> information) are very useful features. But does it make sense to > keep > > >>>>> those active for very technical pages? > > >>>>> > > >>>>> For example, when viewing details about a tag, > > (Main/Tags?do=viewTag), > > >>>>> why should people be allowed to comment? They might wrongly think > > that > > >>>>> they're commenting on a tag, but that's just one complex page that > > >>>>> handles almost everything about tags, so a comment like "this tag > > has a > > >>>>> typo" doesn't help at all. > > >>>>> > > >>>>> Other pages should have no bottom tabs as well: user directory, > blog > > >>>>> category management, the whole scheduler space, share by email... > > >>>>> > > >>>>> While the homepage is a technical page (by default), it does make > > sense > > >>>>> to leave the comments active, since it's the entry point for every > > user > > >>>>> (although I think that the messaging system is a better way to send > > >>>>> global messages). > > >>>>> > > >>>>> > > >>>>> IMO, the advantage is that we're hiding actions that are rarely > > useful, > > >>>>> but could be misused. The disadvantage is that we're breaking the > > >>>>> universality of the UI. > > >>>>> > > >>>>> I'm +1 for hiding, fewer mis-usable features is always better. > > >>>> > > >>>> What if admins want to leave comments on a tech page modified by > > another admin to ask some question for example? > > >>> > > >>> Sending a message to another admin should be done by... sending a > > >>> message, not by commenting. A direct message will reach a user faster > > >>> than hoping that the target user will stumble upon the page and read > > the > > >>> comment. > > >> > > >> If you're saying that comments are useless then we should remove > > comments… :) > > >> > > >>>> Said differently, shouldn't bottom tabs (comments, attachments, etc) > > be visible to admins for example? This could be achieved by only giving > > view rights to non admins by default on tech pages. > > >>> > > >>> Tech pages aren't supposed to be viewed only by admins. They're > useful > > >>> pages for every user, so they should be visible (view tag cloud, view > > >>> documents tagged with a specific tag, view the list of users, browse > > >>> blog categories...). And not having view right doesn't mean that the > > >>> bottom tabs will be hidden. Just the "add comment", "add attachment" > > >>> actions will be unavailable. > > >> > > >> ok my bad, I meant edit/comment rights, not view rights. > > >> > > >>> And even if adding is disabled, but why should this information be > > >>> visible to any user at all? Forbidding edit still means that a user > > >>> wanting to see which pages are tagged with "needsreview" will see a > > "Hey > > >>> John, could we have an undo to tag renaming?" comment. What would you > > >>> think if you saw that? > > >> > > >> Again if your point is that comments are useless then we should remove > > comments. I think there's a place for comments but it seems your > discussion > > is actually asking us to define more precisely what is the use case/need > > for comments. > > >> > > >> Also I think there's a difference between a Tag Dashboard page which > is > > a technical page but for end users and a technical page not for end users > > (i.e. hidden page). Both will need different solutions I think. So this > > proposal should address both needs. > > >> > > >>>> Another use case: imagine I'm an admin and I want to modify a tech > > page and I'd like to add an attachment to that page… IMO bottom tabs are > > still useful for admins on tech pages. > > >>> > > >>> This isn't about disabling attachments and comments. The bottom tabs > > are > > >>> almost an _invitation_ to do stuff. Without them, it is still > possible > > >>> to go to the attachments page by clicking on the "Attachments (0)" > link > > >>> below the title. De-contextualizing these actions will reduce the > risk > > >>> of associating a comment/attachment with a particular view of the > > >>> scripted page. > > >> > > >> If the bottom tabs are removed then those links will also need to be > > removed obviously since otherwise a user can click on them... > > >> > > >>>> IMO the issue is different. If a tech is not supposed to be modified > > by the user then users should have only view rights on the page and NOT > > edit rights. This will solve this issue. > > >>> > > >>> It's not just about changing, but also about what's visible on the > > >>> screen, and the usefulness of such information vs. the number of WTFs > > >>> generated. > > >> > > >> I don't see any WTF. For me any page that is a end user visible page > > can have comments without any WTF. For example on the tag dashboard page, > > someone may comment and say "how do I get the tag dashboard to display > > xxx?" or anything else in just the same way it's done on any other page. > > >> > > >> In addition I'm actually finding the removal of the bottom tab a huge > > WTF. As a user I know what a page is, and if I see those tabs are not > > present on some pages, I'll think "what???? WTF? Why is there not tabs > > there…. > > >> > > >>> Forget about admins, they will still be able to add comments > > >>> and attachments. Think about simple users searching for stuff and > > seeing > > >>> a comment completely unrelated to what they're searching for. > > >>> > > >>> I forgot to say that this has already been done in a few places, and > > >>> nobody complained about the missing things: > > >>> > > >>> http://dev.xwiki.org/xwiki/bin/view/Main/Tags > > >>> http://www.xwiki.org/xwiki/bin/view/Main/Search > > >>> http://www.xwiki.org/xwiki/bin/view/Invitation/ > > >> > > >> It's not because it's been done that it's an accepted > > strategy/decision. I've seen those and I've always been uneasy about them > > and they've been done without any strategy whatsoever… > > >> > > >> All I'm saying is that we need this discussion because we need to know > > 1) if we want to remove bottom tabs 2) and if so, on which pages. > > >> > > >> ATM it's not clear for me at all. > > >> > > > > > > No, I'm not saying that comments are useless in general, I'm saying > that > > > there are certain pages where they shouldn't be displayed. And I > thought > > > I've been clear enough, but apparently not. Let me try again. > > > > > > There are content documents, and there are actions. Some actions are > > > implemented in VM templates, some straight in servlets or Struts > > > actions, some in scripted documents. There are no comments on the > > > Registration page, even though its code comes from a document. We can > > > find a valid use case for comments on the registration page (for > > > example, a user could try to warn others that "Hey, the user name is > > > case sensitive, make sure you choose one accordingly since you'll have > > > to respect the case when logging in"), but that doesn't mean that we > > > should enable comments on the registration page. This an an _action_. > > > People go to the registration page to _do_ something (create a new > > > account), they don't go there to _read_ the registration form in case > > > there's something interesting there. > > > > > > There are many examples of actions where we don't have comments and > > > attachments and the other tabs, and nobody ever asked for them > (renaming > > > a document, logging in, editing the page rights, the administration > > > pages, to name just a few). Speaking of administration pages, they are > > > all stored as documents in the wiki. But we don't display their > comments > > > and attachments in the administration interface. It is possible to > > > manage their attachments, though, so it's not like they're completely > > > disabled for those pages. And I'm not proposing to disable them. They > > > are valid and have their purpose, but they shouldn't be displayed to > > > users that just want to _do_ stuff, using the action document as it is > > > supposed to be used, as a way to perform actions. They would be > > > cluttering the UI needlessly, and clutter isn't good. A good UI should > > > be clear and simple. Removing as much distractions as possible is good > > > way towards simplicity, and thus usability. > > > > > > Code should be optimized so that the performance is better for the the > > > most used branches. Similarly, the UI should be optimized for the most > > > common use cases. How many users really have to add comments on an > > > action document? How often do administrator really leave important > > > messages to other administrators on wiki documents? Very rarely. Does > it > > > make sense for this odd use case to keep the UI cluttered? I doubt that > > > users will be baffled more by the fact that comments are missing on > some > > > actions than by the fact that you can actually have comments on > actions. > > > While you and I know that "everything is a document" in XWiki, normal > > > users just view actions as actions. Registering is an action, logging > in > > > is an action, searching for documents is an action, browsing documents > > > by tags is an action. The fact that logging in is done through several > > > VM templates, Struts actions and internal XWiki components, while > > > browsing tags is done through a wiki document, has no significance to > > > the simple user. > > > > > > For some actions/documents it is clear when the main purpose is for > > > users to _do_ something or to _read_ something. Sure, there's some > > > reading involved in every action, and there's some doing involved in > > > every content read. For some actions it would be debatable in which > > > category they fit better. It would be hard to come up with a clear and > > > precise rule. I can't come up with one. Can you? > > > > > > That's why I'm proposing to just accept that there are documents > > > intended to be used mostly as action pages, and in that case it is OK > to > > > hide the bottom tabs. That's all I'm asking. Do you agree or not with > > > this basic choice? > > > > > > As for the actual decision of which documents fall into this category, > I > > > think that it's OK to trust the opinion of the committers. We don't > need > > > to decide now, we can improve things as we go along. > > > > > > (I agree that the title of the proposal could have been better, since > > > "technical pages" isn't a clear enough term) > > > -- > > > Sergiu Dumitriu > > > http://purl.org/net/sergiu > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
