====== Usability ====== ===== WYSIWYG Editing ===== >>> Only as a note to [[http://www.fckeditor.net|FCKeditor]]: this WYSIWYG-editor seems to integrate quite easy into existing Content Management Systems and - as a sample - works well with Open Source CMS [[http://www.content-builder.de|Content*Builder]]. As far as I see (and read) FCKEdit produces very clean XHTML-code (based on DOM). There are instructions on integration available on this blog: http://apassant.net/blog/2006/06/25/integrate-fckeditor-in-dokuwiki/ ===== Single section locking ===== It would be nice, if editing a section would only lock this specific section of the page. We're having problems in our installation, when multiple people want to cooperate in writing a page. > This is not possible with the current way of handling sections and saving data. --- //[[andi@splitbrain.org|Andreas Gohr]] 27.10.2004 15:10// >> What a pity. But by the way, it seems to me, that edit lock doesn't work at all. It notices the concurrent modification, but it doesn't warn, that somebody else is editing too. [[zslevi@gmail.com]] ===== Edit Summary Alert ===== Could the engine warn the user when the Edit Summary field is empty (blank)? We're not used to using it to describe in a short sentence the changes made, so we forget to use this new feature. Could a warning just like the "Unsaved Changes" pop up? -- 2004.10.21. > Hmm I don't like the idea of an additonal popup... but I will think about it. >> It should be optional, configured through local.php of course. I expect DokuWiki WikiSite to remain without this alert enabled. >>> Such popups are a big no-no from a usability point of view. Isn't there a way to make it more noticeable instead? Like placing it above the edit box, below the button tool bar? Place the initial cursor there, or use color or something like that to make it really noticeable. Maybe when you start typing in the edit box, JavaScript puts a message "edit the summary" in red, inside the summary box. --- [[http://www.it.iitb.ac.in/~sameerds/wiki/doku.php|SameerDS]] 23 Jan 2005 > Now the summary turns red if missing. --- //[[andi@splitbrain.org|Andreas Gohr]] 2005-02-05 20:27// >> Is it complicated to disable the "Save" button until "Edit summary" is entered? From my feeling it is fair to provide other community members with a little excerpt from what I was doing. On the other hand I'm forgetful by myself when it goes to enter log message - help to be a better team player ;-) --- //[[dokuwiki@dekamerone.de|Dekamerone]] 2005-03-10 16:26// >>> IMHO: I quite like that it turns red and doesn't hinder you. Otherwise it would come to be despised like the shut down messages on Windows Server 2003. The summary would be filled with "asdfbdfasdsadj" type entries, or sarcastic "I just wanted to sort out a spelling mistake, ok?!" --- // [[lee_oades@yahoo.co.uk|Lee Oades]] 2005-06-20 15:30// ===== Flexible Edit Toolbars ===== One of the mods I have made to my copy of dokuwiki is to add some extra buttons to the edit toolbar (ones that insert file, code tags and a timestamp). It got me thinking about whether we could have something like custom toolbars, perhaps just an array in the dokuwiki config file that allows the buttons to be turned on or off ? That way everyone could just have the buttons they wanted. > Sounds like a good Idea! --- [[andi@splitbrain.org|Andi]] >> Another way of allowing easy addition of extra buttons would be an include file like the header and footer one that is called after the last button but before the end of the row - then any outputted code would be in the correct spot. ===== Input Buttons ===== Before latest release, the buttons on the header and footer bar did allow the user to right click on them under Mozilla and open a new tab/new window that follows the link. Now, without the tag, it's not possible. Can this be allowed, without breaking the new input button's concept? Thanks. -- 2004.09.16. > No I think I can't do anything about it without changing back from forms to links - Maybe you can file a feature request for Mozilla to allow middle clicks on form buttons - hey maybe even a simple extension could be written to achieve this? >> I moved this from [[Wiki:Bugs]] to here, to ask who has any more ideas about this? I prefer the way the buttons are working now, but I'd also like to have the possibility to use the right button to open new windows/tabs while I browse a DokuWiki-enabled WikiSite. -- 2004.09.21. >>> Just a few thoughts: in my opinion, buttons should be used to **submit** things, not to make fancy links. Although they indeed seem fancier as buttons, using a simple link would be more intuitive and consistent. After all, they are links, so why use buttons? Anyway, css can make fancy links too. =) -- moraes, 2004.09.26 >>>> In general you're right. But the buttons serve a second purpose - they make sure no search engine spider opens the edit mode and locks the page. --- [[andi@splitbrain.org|Andi]] >>>> Hmmm. I see. That's indeed a good purpose. ^_^ Ok, so if the purpose is disallow robot's access to the edit mode, maybe using the button just for 'edit' would make things better? Hmmm, just thinking... ===== Search Only A Namespace ===== It would be useful to have an extra search option that restricts the search to only a single namespace, or set of namespaces. This is useful if you are using a namespaces for projects and are only interested in references in that one project. --- //[[rob@tarasis.net|Robert McGovern]]// * subscribed :) --- //[[freddyw@gmx.net|Freddy]] 2005-11-10 20:40// One possible search-syntax for this would be e.g. "word1 word2 @namespace". ===== Quick syntax helper window ===== I was thinking about some kind of syntax quick helper. This could be a window triggered through a link in the edit mode. Newbies always get lost with syntax format... so I think that, additionally to the syntax formatting page, a window could be used for a quick help when you are already editing a page. It could be divided in several pages, with a table of contents in the first page. What do you think? I've already done a schema for this, separing the topics and including them into a dynamic page depending on the request. But I don't know how I include a javascript to open the window: the parser don't let me do it! Can anybody help? :-| -- moraes, 2004.09.26 ===== Sidebar ===== Does anyone else consider a SideBar an usability feature that is missing from DokuWiki? I've seen other WikiEngines that allow for a sidebar to be used as a navigation-aid, which I think helps to increase the usability levels of a WikiSite. I find myself browsing through many clicks before I'm able to reach the page I was targetting at the beginning, mainly because I use namespaces with levels deeper than 2. An editable sidebar, which can be activated / de-activated, would help users to access the content faster and in a more practical way, which is one of the goals of Usability, right? --- //[[jose.monteiro@dowedo-it.com | straider]] 2005-02-14 19:56// > Another way to improve this kind of usability would be the tight integration with [[Wikimaps]], which besides being "automagically" created also drive the user toward the end-page one is looking for. This is open to discussion because I see no advantage in opening a feature request that only I am missing. --- //[[jose.monteiro@dowedo-it.com | straider]] 2005-02-14 19:56// >> I think it would be a useful feature. I shrink the displayed wiki width already, as I find my normal firefox window size (which works well on other sites) makes the line size too long for comfortable reading. For now that leaves a blank column on the left. >> Some ideas: * configurable option to display navigation column on left, right or nowhere. * default to a namespace index. like the index page, but only show namespaces. * if it exists display a navigation page, a normal wiki page displayed with a different style, mainly smaller fonts. It would then be up to the wiki user to construct a page that was entirely headers, separators and links, which would display well in the limited width available. * if displaying a navigation page, you could even pick up the navigation page from the current namespace if it existed, if it didn't exist, look for a navigation page at the next higher namepace, and so on up to the root wiki data folder. Below example and [[http://wiki.jalakai.co.uk/wiki/|test site]] have been updated to support namespace based sidebars as described. >> --- [[chris@knowledge.teevee|Chris]] 2005-02-17 >> >> PS. this is surprisingly easy to implement, [[sidebar example|example]] --- 2005-02-18 >>> Will this feature be implemented in future DokuWiki releases? Maybe this is the killer feature to convince non-Wikianers when browsing the site ... --- //[[dekamerone@gmx.de|Dekamerone]] 2005-03-10 16:48// >>>> I've been trying to find the best wiki for our needs and I know that Dokuwiki is it. I've started to put our documentation into it knowing that a sidebar solution can be added later. >>>> For me, the sidebar //is// the number one missing feature at the moment. As good as the sidebars are that I've seen so far, they don't quite meet the requirements that we have. Here are some ideas for comment - please forgive the brain dump :-): * Defining the hierarchy: * if a tag were added to a page that indicated which other page was its parent, that would be all the information you would need to construct a hierarchy. No tag means not included in the tree * or make it an optional field on the edit page - parent id * or a marker file in the data directory - with the same name as the page, suffix .nav.txt - and contains just the id of the parent? * optional text label for the tree. Default to first Heading on page or ID? * during the saving process, the sidebar is rebuilt. * Sidebar Semi-auto generation * Sidebar page exists as a wikipage - so logso, custom formatting, text etc still possible * you define a tree root page id somewhere on the page * the child pages are then added automatically * multiple roots can be defined * custom icons would be nice * In Use: * ability to collapse/expand subtrees * tree auto-expands to the current page * tree highlights current page always * expanded/collapsed nodes retained across pages * ability to bookmark any page through the browser (i.e. unlike with frames) * drag width of sidebar - close all together (pin, unpin?) >>>> Did I miss anything? :-) >>>> I think that the above defines a powerful and flexible sidebar that is in keeping with the Dokuwiki way. >>>> --- //2005-06-16: [[lee_oades@yahoo.co.uk|Lee Oades]] // I think that the ideal was this: * That sidebar were a plugin * We could have several sidebars * We could edit sidebars (I only see that in http://wiki.jalakai.co.uk/dokuwiki/doku.php?id=tutorials:dev:navigation_sidebar) in easy way and as part of wiki source. Example: [[start]] [[info]] This is a discussion usability.... More discussion pages: [[discussion:wiki_cms]] .... It produces left and right sidebar and central wiki page. (Xan: DXpublica ATTTTT telefonica.net) ===== Home Button position (back-link to entry page of the DokuWiki) ===== What about placing the back-link to entry page more prominent? The most annoying thing for the usability testers when browsing my testsite was not to find the link back to the root of the website. They were looking for it on the upper left and got very unexpecting and demotivating results when clicking there. Just change the buttons upper left and upper right? -> should do the trick to fulfil expectations of website guests I guess. --- //[[dekamerone@gmx.de|Dekamerone]] 2005-03-10 16:59// > This is a good point, especially as the start page link does not have any colouring to indicate it is a link, even when hovered over (although the cursor does change). I have not swapped back-link and start links, but I have given the start a similar style to back link. An alternative, would be to place a start button, labelled "start" on the upper button bar. --- //[[chris@knowledge.teevee|Chris]] 2005-03-10 22:01// >> I agree. There should also be som separation on what the different buttons act on. Search, login and index should be in a section separated on "Edit page", "old revisions" and "back to top" since they act on the current page. Maybe something like this: ^site|homelink || login| ^operating on the whole site|index | recent changes | searchbox| ^page|pagename | old revisions || ^operating on the current page|edit page | ||| ---- I have done away with the backlink functionality of the page title. Instead, %%[[wiki:discussion:usability]]%% is actually three links. The wiki part links to //index// in the wiki namespace. The discussion part links to //index// in the discussion namespace. Finally, the usability part is not an active link at this point, though I might make that do the backlinks. I have also swapped the start page link and the %%[[ ]]% part. --- 2006-01-30 13:05cdt ==== Frames ◊ Redirection ==== Here I present a method to break your main Dokuwiki site out of frames (note that this method also works on individual pages within your wiki as well.) To break the main page out of frames automatically you need to edit the main.php file of your favorite template (barring that such template hasn't already given you this option.) I use a modified version of the ACH template. Here are the example changes you need to make to the main.php file: \\ ''Redirection'' Have you have ever wanted to redirect a single wiki page to another wiki page automatically? Here is an example you can use to make this happen: Redirecting you to [[http://insecurity.org/]] -- click the link if the redirect doesn't work. Just substitute Fully Qualified wiki URLs instead of the http://insecurity.org/ above. For example, to redirect http://dw.ccsh.us/doku.php?id=kittens (because the kittens have grown up and they are now Cats) to the correct wiki page about cats you insert the following code (by itself) on the wiki page about kittens that you want to redirect to the page about cats - Redirecting you to [[http://dw.ccsh.us/doku.php?id=cats]] -- click the link if the redirect doesn't work. Enjoy --- //[[http://insecurity.org/|Bill Jones]] Sunday 02nd of July 2006 08:13:50 AM// ===== Trace and breadcrumbs show Link to current page ===== According to Usabilty guru Jakob Nielsen this should be avoided (and of course I don't like it either). Now the current page in breadcrumbs or traces is clickable. See also [[http://www.useit.com/alertbox/within_page_links.html|Article of Jakob Nielsen about "within page links"]]