[xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?
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. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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? 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. 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. 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. WDYT? Thanks -Vincent
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.
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. 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?
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.
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. 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/
WDYT?
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
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. Thanks -Vincent
WDYT?
Thanks -Vincent
Hi, Regarding this topic what I would propose is to have an "Administer Page" section in the menu (just like we have for Wiki and for Space). It will contain: * "Look & Feel" ** "Presentation" - giving the opportunity to change the style just for one page (maybe different layout for apps' WebHomes or different ColorTheme, etc.) ** "Page Elements" - what this mail was initially about, I will detail later ** "Panel Wizard" - we could leave it just at space level, but could be interesting also at page lvl * "User & Groups" ** "Rights" - this will contain what we currently have under "Edit" -> "Access Rights" Having the "Administer Page" it would be very easy for someone to Add/Remove what metadata he wants to see for a certain page. Having that section customizable is better than hiding them programmatically without the ability of a reverse (from the UI). Comments and attachments can be "useless" depending on the type of the page. Having this mechanism at a page lvl it will be very easy to define the use cases. For example, when creating a new app by using the AppWithinMinutes, in the wizard we could ask the user if he wants his app pages to have "Comments", "Attachments", "History", "Info", etc. functionality displayed by default. He could select if he wants this features to be enabled/disabled for "All Pages" or just for the "App's WebHome". Like Sergiu said we could disable these features for technical pages. Right now in XWiki we don't have the concept of technical page and this is rather implemented with the Hidden mechanism. Anyway our hidden/technical pages are in fact application pages. The example Sergiu described is about the Tags app. Also User Directory, Scheduler, Share by email, etc. are apps. Accordingly to the example I gave we could consider SOME default XWiki apps not to have the "Attachment", "Comments" functionality. Of course we will have exceptions and these will be content applications like Blog, User Profile, etc. Depending on how we see the wrapping at a user mental model, we could consider "User Directory" page to be the "Users" app homepage, where "User Profile" entries are entries in this app. In this use case the homepage could have the "Comments", "Attachments" functionality disabled, while the rest of the pages have it enabled. So from a technical point of view we have: - "Page elements" at a wiki lvl - "Page elements" at a space lvl (app lvl) - "Page elements" at a page lvl (app's wehbome) that overrides the former with some initial values for our default apps and with the ability for the user to customize what we wants depending on what application he is building. Regarding the logic behind hidding/showing the "Comments", "Attachments" functionality for our default apps this depends on questions like: - is this app an internal app or these pages can be seen by users? - does this app allows attachments? - the content of this page is static or dynamic? should the user improve/comment on the content of this page? - etc. Thanks, Caty On Sun, Jan 20, 2013 at 9:48 PM, Vincent Massol <[email protected]> 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.
Thanks -Vincent
WDYT?
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Wed, Jan 23, 2013 at 8: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? > So I agree with the rule that "action" pages don't need comments. Also as an addition to the rule we can also make a difference between "static & dynamic" pages and "action" pages fall into the static category, because their content is usually the same and the normal users will not change it. Thanks, Caty > > 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 >
On Wed, Jan 23, 2013 at 7:20 AM, Sergiu Dumitriu <[email protected]> wrote:
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.
I strongly agree with this paragraph.
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?
+1.
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.
+1. -- Jean-Vincent Drean, XWiki.
On 01/23/2013 07:20 AM, Sergiu Dumitriu 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.
In most of the cases I've seen, pages in the wiki usually belong to one or more types, implemented using classes (I rarely have seen a wiki used with "free" wiki pages) and all that is beyond these types is not "content" for the users of the wiki, therefore not-commentable. I customize frequently layoutExtraVars or some space prefs to display the comments only for a specific type of page. This is to say that to me, the separation between action and content makes a lot of sense, even if we know that it's all an xwiki document, users in general don't care/understand. It's not because something is possible and that it costs nothing to provide an UI for it that we actually must do it. I also think that few users would notice that comments tab is missing: you notice that it's missing only when you actually want to comment, and you generally want to comment on some content (not a login form, for example). So i'm +1 for hiding the tabs on some pages (potentially, yes, with some special UI accessible to admins, which will take them to "viewer=attachments", assuming that not all admins of the wiki know how to edit an URL and what to put at the end). Now, about which documents should have hidden comments / attachments in the default xar, I would say we should vote the list indeed, since some pages might be tough to call. Anca
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)
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) ** 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 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
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. 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. 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'. 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 >
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 >
participants (7)
-
Anca Luca -
Ecaterina Moraru (Valica) -
Guillaume Lerouge -
Jean-Vincent Drean -
Sergiu Dumitriu -
Sergiu Dumitriu -
Vincent Massol