UserSettings Panel
Last edited by DarTar:
Replaces old-style internal links with new pipe-split links.
Fri, 20 May 2016 07:38 UTC [diff]
Replaces old-style internal links with new pipe-split links.
Fri, 20 May 2016 07:38 UTC [diff]
See also: UserAccountModules
Some preliminary ideas for an improved UserSettings panel.
Feel free to add content/suggestions.
The issues I'd like to address in this page are the following:
- What options should be user-configurable?
- For each option, how should Wikka store it?
- cookie parameter
- session parameter
- user_table field
- other
- User table field(s) or maybe a separate user table that stores only the settings that are not default. Decision would depend on efficiency; would require some analysis... --JavaWoman
- How should user options be arranged/grouped/displayed in the UserSettings page?
I also propose that we keep the login/logout interface separate from the user settings page.
- Definitely! --JavaWoman
Preliminary list of user-configurable options
- User related
- Email address [string]
- Password [string]
- Date/Time
- Time zone [list]
- Date format [list]
- Layout
- Default skin [list] (beta - see TestSkin)
- Custom skin [link] (beta - see TestSkin)
- Custom menus [link] (forthcoming?)
- Editing
- Doubleclick Editing [boolean]
- WikiEdit GUI [boolean]
- Changes & revisions
- RecentChanges display limit [integer]
- RecentChanges to show per page --RyanKnoll
- Page revisions list limit [integer]
- Page revisions to show per pag --RyanKnoll
- Comments
- Show comments by default [boolean]
- follows text in comments box: Display comments by default --RyanKnoll
- Paged comments per page [integer] (beta)
- sounds a bit confusing that way, how about this: Comments to show per page --RyanKnoll
- Comments start page [list] (forthcoming?)
- Wouldn't this be more clear (slashdot style): Order comments by: [newest First, oldest First] --RyanKnoll
- Log-in
- StayingLoggedIn - checkbox
- Shouldn't this appear in the (separate) Login/Logout interface instead? -- DarTar
- I am not sure. Mediawiki does it like you propose, but I find it more logical in the usersettings. What do the others think? --NilsLindenberg
- Other
- external links? all links? open in new versus same window (I always hack wikka.php so that Target=_BLANK)
- Bad for accessibility, at least. I don't think this should be an option. People can always open a link in a new window if they want to. (And, Mike, while you're hacking - that should be target="_blank" if you even want to keep it valid XHTML transitional. :)) --JavaWoman
- Hiya JW. How is this bad for accessibility? (more info needed so I understand the point) I sometimes embed wikka in a frames page (ya ya, I know you hate frames {grin}) so opening external links in new pages would be useful....as for the "people can always" point....this goes to our conversations elsewhere...many web users don't really have a clue how to do this....so giving them the option (with a default set-able by the admin). In addition, moving to an "outside" site by clicking on a link usually means that one doesn't log out of wikka properly and therefore leaves cookies behind....this can be a problem for kids working in schools because that means another kid just opening the browser to the wiki will be logged in as another users account....and ya, I do put the quotes in usually {grin}. -- Mike (aka GmBowen)
- First, forget about cookies. Session cookies are destroyed only when the browser session (all windows) is closed; and permanent cookies for a logged-in user remain across sessions - that's why they are permanent cookies. This is the way user management is designed in Wikka.
Opening new windows not on request of the user confuses the hell out of blind users who can't see they're suddenly in a new window (and if you do notice, switching windows isn't as simple as a mouseclick - because you can't click a mouse!); and many others, too, when they are browsing with the browser full-screen.
So educate your users how to use their browsers (and point them to Mozilla, Firefox or Opera while you're at it), change your installation if you really want to - but I am absolutely opposed to making Wikka less accessible - even as an option: that would be a move in the wrong direction.
References: See Guideline 10 / Checkpoint 10.1 at:
http://www.w3.org/TR/WCAG10/wai-pageauth.html#gl-interim-accessibility
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-avoid-pop-ups
--JavaWoman
http://www.w3.org/TR/WCAG10/wai-pageauth.html#gl-interim-accessibility
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-avoid-pop-ups
--JavaWoman
- There was a request for suggestions for features that could be set by the user, that's all it was....and I'm all for giving control to users. Right now, control for opening windows is either the wikka default (same window) or a hack like mine....the user has no control. My sense is that some users would prefer one approach, and other users the other. My preference is not to force either approach on a user but rather facilitate users making their own decisions. However, I'm more than content to accede to whatever decisions the developers make w.r.t this settings panel. Cheers, GmBowen
- Mike, you say "Right now, control for opening windows is either the wikka default (same window) or a hack like mine....the user has no control." - but that really is not true - the user does have control, with every browser, and - more importantly - for every link separately. OTH, if you let a user change the behavior of the site, that may seem like control, but actually gives less control since then all external links would behave the same. But it's easier to open a link on purpose in a new window (or a new tab) than it is to override a link that "wants" to open in a new window to open in the same window instead. So your proposal would not "facilitate users making their own decisions" but quite the opposite: it would actually make it harder to decide how to open each link separately: same window, new tab, new window. --JavaWoman
UserSettings panel design
After you've added your suggestions in the list above, please edit accordingly the source of this sample HTML form- I don't think having the links for skin and menus within the form is a good idea - you'd effectively be leaving the form - and how do you get back? You may even forget...
Maybe have menus just a separate page, and in user settings form below have just a checkbox to create a user-skin IF it doesn't exist already (i.e., don't even show that checkbox when the file exists). And even that might be overkill - just having that on a separate page, too might be better. -- JavaWoman
- I agree that allowing the user to quit the form before posting it is not a good idea. So, ok for moving links to other pages out of the form. OTOH, I think it is really important to group all the user-configurable options in the same hub. I like the MediaWiki approach, with a UserSettings page containing a number of subpages for each 'group' of options. Menus, skins etc. might become subsections of the same page. -- DarTar
- Also don't forget that a non-registered user should be able to choose a skin as well - only have that choice stored in the session rather than the database; i.e., no personal default. So it's easier to just have a single page for everyone that just behaves a little differently for registered and non-registered users. --JavaWoman
- That's why I had proposed that for each option we decide whether it is better to store it in the database or in a session parameter. But I like the idea of the same page behaving differently for registered and non-registered users. This implies, though, that those settings that are displayed to both kinds of user are susceptible of being stored in the database AND in session parameters -- DarTar
- Date and timeformats have some problems:
- You can't live in Nepal (not all time zones have whole or half hour offsets!)
- So, what are you suggesting?? -- DarTar
- Date and time format should be separate; with an extra field to indicate order
- Agreed -- DarTar
- Configuration should have the (ISO) defaults, overridable by WikiAdmin
- Agreed -- DarTar
- No dropdowns for format, but text entry fields, with an explanation (help window) for formats
- This makes sense, although how to set a format becomes even less intuitive to the user. I was actually thinking of replacing the php syntax with something more accessible like a set of radio options:
But this goes exactly in the opposite direction of what you are proposing. BTW we shouldn't forget that once i18n is done, the date formats will probably depend on the kind of locale set by the user/system administrator -- DarTar
- Move the "Server time is 12-26-2004 20:50:45 (UTC)" example to below the date & time settings (and make it) so you can see the effect of the formats chosen (after update)
- Agreed -- DarTar
User Settings
CategoryDevelopmentActions CategoryDevelopmentUserAccount
