Usability

Archive for the ‘Usability’ Category

Some Tips To Make Your Wiki Really Work

March 15th, 2010 by Dario Solera | 2 Comments | Filed in Community, Usability

Last week I had the chance to chat with some folks at Microsoft Italy about STW. They wonder why wikis don’t really take off. I mean, they did take off after all, but they could be used much more widely (and wisely).

My personal opinion is that wikis are a valuable knowledge sharing tool, but they are still too cumbersome to use. It’s not writing stuff, but it’s managing information that is hard. Sharing and discussing ideas, documenting processes and sharing files are all very easy tasks. When your wiki is small.

The biggest single problem with wikis is that keeping them tide and clean is very, very difficult. With dozens users and hundreds or thousands pages, you absolutely need a strong discipline in every single participant, otherwise the thing will simply run out of control in no time. The hard part is making users understand when and how they should create new pages, how to categorize them and how to upload and share files and documents.

We geeks take these things seriously, so for a team of software developers maintaining a wiki is pretty straightforward. But what about “normal” people?

Here are a few tips for keeping a wiki that make sense (using ScrewTurn Wiki, obviously):

define namespaces upfront, making pondered decisions; this step really depends on the content of your wiki, but try not to mix areas maintained by different groups
define a small set of rules for creating new pages, for categorizing them and for managing files/attachments, that are valid for everyone that uses the wiki
link/insert such rules in the main page of each namespace, as well as in the editing screen (see the Content Editing tab in the admin interface)
as a wiki administrator, subscribe to RSS or email notifications for all namespaces (so you catch errors and broken edits immediately)
review the rules every once in a while, to adapt them to the patterns that will emerge during the lifetime of the wiki
evaluate whether to “personalize” rules for each group in the wiki, because most probably each group of people will use the wiki in a slightly different way
avoid to lock the wiki down, at least at the beginning, because most people will not even think about editing pages that do not belong to them, but when they catch errors they can fix them on the spot without bother anyone else
strictly avoid assigning permissions to individuals, as that quickly becomes a maintenance pain; use groups instead
promote the usage of page discussions so the page author learns how to improve his writing with respect to the actual readers
if someone breaks a rule, contact him/her and learn why that happened; update rules if the arguments are valid.

As I said, some discipline is required, but in order to make the wiki work, you have to really make maintenance a collective, shared task. It surely takes some time, but I think it’s really worth the effort.

Any other tip or suggestion?

New Page Rollback Behavior

July 25th, 2009 by Dario Solera | 5 Comments | Filed in Community, Software Design, Usability

Since version 3.0.0.157, the page rollback feature has changed. Previously, when you rolled back a page, the revision history would get deleted up to the target revision, actually destroying content. With the new behavior, the current revision is backed up and the target revision content is copied to the current revision. No data is deleted at all.

This behavior is a bit less intuitive than the previous one, but I think it’s safer and therefore must be preferred.

Here is the original discussion in the forum that initiated this change.

Version 3.0 RC0

April 1st, 2009 by Dario Solera | 2 Comments | Filed in Usability

Version 3.0 RC0 is almost ready. I did some changes to the provider model (a couple of new methods) in order to gain quite a lot of performance when pages are many (as in many hundreds, or thousands).

The tests I’ve done showed that loading the wiki index (AllPages.aspx) with 1,000 pages* takes about 6 seconds (time-to-first-byte, measured using lori) plus 1 second for browser rendering (Firefox 3.0.7). It’s a lot of time, actually, but the real problem is that you cannot do anything meaningful with a list of one thousand pages. Some kind of better browsing method is needed here (even classic pagination is useless in my opinion).

I want to point out that fetching the bare-bones page list from the provider takes virtually no time – the real work consists in reading page contents (titles, dates, authors, etc.), building the list in memory and sorting it according to the column selected by the user (title, creation date/time, author, etc.)

I also tried with 50,000 pages (yes, 50K), and it took something like 3.5 minutes for loading plus 2 minutes for rendering the screen (that’s 17 MB of HTML!). Firefox was consuming 700+ MB of RAM (and no, I did not test with IE). This 50K test allowed me to fix a connection leak in the SQL Server Pages Storage Provider.

Similar times are observed while loading the Wiki Pages tab of the administration interface (AdminPages.aspx). In that case, you can filter pages by name or title, but it still takes the same time given that the filtering is done in memory.

Opening a single page takes less than 0.2 seconds, which is fine (keep in mind that the SQL providers don’t cache data in memory, so it’s a good result).

The one single thing that scares me regards the search engine. I filled the thousand pages with 5 paragraphs of lorem ipsum and rebuilt the index (3 minutes or so). The index contains now 1,165 words** and 449,000 matches. Estimated disk space is 9.13 MB, but it is actually 16 MB. The problem is that, loaded in RAM, the index takes something like 100 MB. Searches are blazingly fast: searching for lorem dolor takes 0.2 seconds for index seek, plus 7 seconds for rendering the results screen, containing 1K items. In this case, the big issue is memory consumption which is a bit too much I think, considering that after the search the w3wp.exe process occupies 600 MB of memory.

I’ve got to scan for recent bug reports in the forum, and then RC0 will be ready.

P.S.: I forgot to mention that users’ pages will not be implemented in version 3.0. They were turning out too much bulky in my opinion. They require to be thought-out better.

*) I’m using SQL Server Storage Provider against SQL Server 2005 Express (2.0 GHz dual-core, RAID0 SATA drives, 4 GB RAM, Windows Vista x64).

**) ScrewTurn.eu‘s index contains 3,500-odd words.

Non-content Pages Layout

December 28th, 2008 by Dario Solera | 1 Comment | Filed in Software Design, Usability

While improving the user interface of ScrewTurn Wiki v3.0 I persuaded myself that pages that don’t contain actual “content” (e.g. wiki pages) should be visually disconnected from “helper” pages (e.g. login, profile, etc.).

This visual “shock” might seem an issue at first, but I think that it greatly helps the user figuring out where she is in the website. I looked at some other wiki engines and CMS’ and this pattern is actually normal. Moreover, most websites and web applications also adopt this approach.

Of course behind this decision there is some rationale. For example, if you are performing a login, you should be able to only see the login form and a way to go back where you came from, without being distracted by other navigation possibilities, and the same can also be said for many other activities. After all, choices are bad (just joking!).

For this reason, in version 3.0 the following pages will live in a separate “realm”, visually and physically disconnected from the rest of the wiki:

Login.aspx – Login screen
Access Denied.aspx – Access Denied screen
Profile.aspx – User profile settings
Upload.aspx – File Management
Edit.aspx – Page Editing
Register.aspx – User Account creation
Error.aspx – Error screen
Language.aspx – User’s language/timezone preferences
Operation.aspx – Deletion of discussion messages
Message.aspx – Sending of messages to users

Technically, this is achieved using a new master page (MasterPageSA.master, SA = Stand-Alone), and using a small set of new CSS IDs to allow flexible styling for these pages, which will anyway use the theme set for the current namespace (namespaces can use a different theme each). The sidebar is not present, while the contents of the regular header and footer are still rendered.

After almost three years passed using the “old” interface, this new patter just seems right. The Default theme bundled with the wiki engine sets the width of the body of the new stand-alone pages to a liquid 70%, and the result is, I believe, visually appealing.

As you can see in the screenshot, there are two links at the top of the page: Back to previous page and Main Page, allowing you to go back where you came from and to navigate directly to the main page of the current namespace.

As usual, comments are really welcome. BTW, v3.0 Beta is coming.

URLs and Namespaces

August 30th, 2008 by Dario Solera | 5 Comments | Filed in Development, Software Design, Usability

One of the long-awaited features that ScrewTurn Wiki 3.0 will have is the support for namespaces, or sub-wikis. Basically, there will be a root namespace and a number of sub-namespaces, enabling administrators to split the content of the wiki across multiple “groups” of pages, each with its own set of categories and navigation paths. But I don’t want to discuss this feature per se.

Namespaces support creates a bit of trouble with URLs (and this is one of the reasons why Alpha2 is so behind schedule). Currently, pages are identified by URLs in the form http://www.server.com/Wiki/Page.ashx – easy and search-engine-friendly. Ideally, when navigating a sub-namespace, an URL should be like http://www.server.com/Wiki/Help/Page.ashx. It’s worth noting that those URLs are virtual: Page.ashx does not exist in the Wiki (virtual) directory, let alone the Help subdirectory – it’s just a matter of some homemade URL-rewriting. The main problem occurs with files that are related to the page, such as CSS files, images, and so on. In the latter URL, the one in the Help namespace, when the browser attempts to request, for instance, the CSS file for Page (e.g. Themes/Default/Screen_Styles.css) it expects them to reside at http://www.server.com/Wiki/Help/Themes/Default/Screen_Styles.css, which obviously does not exist on the server’s file system: IIS simply returns a 404 error.

The first solution that I developed was a response filter (see HttpResponse.Filter) that searched all the relative-path URLs in the page output with a simple regular expression and patched them so they worked with namespaces. In other words, if the user was navigating a sub-namespace, all relative URLs were prepended with “../”, so they referred to the parent folder of the current page. It worked quite well, but it just felt like a clever trick. A clever trick that surely would bite us sooner or later, with some weird malfunction.

Another feasible solution is to use the query string: a page in a sub-namespace is identified by a URL like http://www.server.com/Wiki/Page.ashx?NS=Help. No more search-engine-friendly* I guess, but it’s a lot easier to manage on the server side. A couple of helper methods correctly handle the query string parameters, and no modification is needed for relative URLs which simply continue to work.

So far, I decided to go for the second solution, which also solves the problem of targeting the main page of a sub-namespace (you just write http://www.server.com/Wiki/?NS=Help. At any rate, http://www.server.com/Wiki/Help would not work except in IIS7 with Integrated Pipeline). As usual, I’d like to hear your opinions.

Update: as Marius suggested in a comment, it might be a good idea to use a dotted notation, for example: http://www.server.com/Wiki/Help.Page.ashx. I think it might work very well, I don’t see any reason why it should not work (moreover, dots are not allowed in page names).

*) I still have to understand why a search engine would prefer http://www.server.com/article-name over http://www.server.com/?Page=article-name. After all, they’re just strings, and from a user’s perspective, there’s no point in remembering a full URL when she can use her bookmarks, or even her search engine of choice. Who actually looks at URLs anymore apart from (I bet a small part of) computer geeks?

KISS in The Real World (Sort Of)

October 3rd, 2007 by Dario Solera | No Comments | Filed in Development, Usability

In the last couple of months there have been a few users reporting issues with the editing page of the wiki engine (Edit.aspx): when the upload directory contained many pictures, the editing page took forever to load, especially the toolbar, whose buttons were displayed with a delay of some dozens seconds.

The problem was quite simple to identify. All the users who reported the issue already nailed down the part of code that stunk. The Web User Control JsImageBrowser.ascx was build (by me, in case you are wondering) quick and dirty, but it worked quite well. At least, with just a few files. It works by rendering a bunch of DIVs, each one containing the pictures and subfolders of a folder in the upload directory.

When I thought about it, I started imagining solutions with heavy use of AJAX, just like anyone does these days (most of the times because it’s just cool), also because version 2.1 already uses AJAX in the revamped editor.

Yesterday I had the opportunity to think about the problem a little more in detail. The solution had to be as simple as possible, to avoid to break things. What was the step that took the most time during the loading of Edit.aspx?

Think a little about it.

It’s not the HTML, it’s the enormous set of pictures, whose previews have to be requested one-by-one to server. It was that simple, but somehow I couldn’t figure it out for weeks. Maybe I didn’t think hard enough.

Anyway, the fix was as complex as a 10-line edit. Nothing changed, except for the fact that the image browser HTML is stored in a JavaScript string, which is rendered to the page only when the “Image” toolbar button is pressed. The previews are still requested one-by-one to the server, but only when you actually need them.

I simple don’t know why this didn’t come to mind before, something like 8 months ago, when we released version 2.0. Go figure.

Quick Poll

September 23rd, 2007 by Dario Solera | 3 Comments | Filed in Community, Usability

A quick poll for all the users: do you use the Data Backup function in the Administration interface?

Please answer here, on the forum.

(I’ve never used in in my life if you ask me, and I find it actually unusable since it takes forever if the files to backup are many. Moreover, it has never worked in mid-trust.)

ACLs Implementation

July 17th, 2007 by Dario Solera | 5 Comments | Filed in Development, Security, Usability

It seems that ACLs are a feature that just about everyone wants, so we’re going to implement it in version 2.1. The implementation is described here – note that nothing is carved in stone, so there might be changes. Also, our implementation is not very similar to any other ACL system I’ve ever seen due to compatibility reasons.

The table above summarizes the two types of behavior that the engine implements. For pages, the first table is used (X means that the action is allowed). For namespaces, both the tables are used: the second one tells whether the current user can create new pages. For file upload directories, again both tables are used, and “Read” means “Download”, “Edit” means “Delete or rename” and “Create” means “Upload”.

In all cases, the permissions for objects that are at an inner level have higher precedence. For example, pages permissions “overtake” namespace permissions. A new page, by default, inherits the permissions of the namespace containing it. The same happens for nested namespaces and sub-directories. For now, it’s not possible to set permissions for single uploaded files.

ACLs will be implemented as an additive layer: each object can have a local ACL, which of course has higher precedence than “built-in” permission levels. There will be user groups, with two built-in groups: Users and Administrators. For each object, it will be possible to define which users and groups can read, edit and create new sub-items in the object.

As you can see, ACLs will be optional, so you don’t have to worry about them if you don’t plan to use them. There are still a number of technical problems to resolve, but hopefully they will work fine. Due to the approach we adopted, this feature is in fact quite difficult to implement, so the release date for version 2.1 has been set to “late 2007″. Sorry for that.

What’s up with AJAX?

April 9th, 2007 by Dario Solera | 17 Comments | Filed in Development, Internet, Software Design, Usability

Last week I’ve been working with ASP.NET AJAX a lot, and I have to say that I just love it. It’s way easy to use and integrate with ASP.NET applications. The Control Toolkit is quite tricky to get started with, but it contains dozens of excellent controls.

So far, I had no problems with it. There are a few documented incompatibilities (for example with ASP.NET Validators, which I personally don’t like much), but that’s it.

There is one thing that I don’t like: the AJAX package must be installed on the server, because it must reside in the GAC. On dedicated servers this is not a problem, obviously. But what about shared hosting servers?

As you might have guessed, I’m speaking about ScrewTurn Wiki. There are many things that could be improved with AJAX, especially the editing and administration pages. Not only it would be possible to increase usability, but probably also the bandwidth usage would be reduced a lot.

I know there are many free AJAX toolkits out there, but ASP.NET AJAX is really well done and most importantly easily integrates in an existing ASP.NET application, so it would be a good choice for ScrewTurn Wiki.

The problem is that it won’t be supported by ISPs in the short term, I guess. I’ll open a poll in the next days to see what the users think about it. Probably the ones who host the wiki on low-end ISPs won’t like it. Since version 2.1 includes tons of changes, I think it would be a nice idea to integrate ASP.NET AJAX. BTW, our ISP does not support it yet (and so far they’ve no plans about it).

Image Wizard

December 22nd, 2006 by Dario Solera | No Comments | Filed in Usability

The new Image Browser that I mentioned yesterday is finally ready. I added a new “wizard” to the editing page that allows you to insert images easily. The appearance (as you can see in the first picture) is quite “raw”, but it works and I think that it’s very useful.

You can add the title, the URL of the picture and, if you want, a link. If you click on the “Pick” button, the Image Browser (second picture) is displayed. You can now browse the images (and folders), and when you click on a thumbnail, a preview is shown on the right. If you click on “OK”, the image’s URL is placed in the proper textbox.

If you need to link the image to something, you can add an URL or use the buttons displayed on the right to insert a link to another image, a link to a file or a link to a wiki page.

There are still a few problems with the generation of the thumbnails, but they’re just minor issues. Moreover, the thumbnails are now always generated on-the-fly, so I want to cache them to save CPU cycles.

Archive for the ‘Usability’ Category

Some Tips To Make Your Wiki Really Work

New Page Rollback Behavior

Version 3.0 RC0

Non-content Pages Layout

URLs and Namespaces

KISS in The Real World (Sort Of)

Quick Poll

ACLs Implementation

What’s up with AJAX?

Image Wizard

About

Subscribe to New Content

Categories

Archives

Meta

Side Projects

About