What’s your Purpose?

So one of the things we’ve been asking a lot lately is:

What is your purpose?

In asking others that, we have also been asking ourselves that. Not necessarily why are we using a tool, but for what purpose are our users supposed to be using the tool. We effectively have no policy surrounding the usage of any of our tools or any guidelines for how staff on creating content in these tools.

I have recently been asked by a number of staff members about whether our department has any guidelines on how things should look on the website, and I can’t answer anything except “no, not as far as I am aware.” It’s one thing if people refuse to use it, it’s another not to have any sort of documentation when people are looking for it. Staff members are not web designers, and may know little about designing content for the web. Most of them will do a handout version of something and simply put that online. That does not always “translate” well.

So, a recommendation for all:

  • have a document that presents guidelines on how to present content on the web
  • include a template
  • and CSS style stuff so that users don’t have to think (or can’t mess up) the little details

I’m sure those seem obviously for most people, but I am amazed sometimes at how little the first one is done.  The last one is normally implemented, but what’s a pretty page if people don’t want to read what’s on it?

Card Sort Reflections & Analysis

In July, I had done a card sort study for the section of the website I was helping to redesign.  Particularly since the new portal I’ve been working on doesn’t have as clear cut categories, we decided to do another card sort.

Reflections
Just a Few Number of Sessions worked fine.  The first time we did the study, we did 5 group sessions and found that we began finding the same results, especially after refining it the first time.  We only did 4 group sessions this time and we still found after the 3rd session, we found nothing new (though that may have had something to do with the make-up of the 4th group).

Timing was an issue. Although it was somewhat an issue the first time too (because it was summer), but this time was almost worse because I had less time between advertising and carrying out the study.  And, although there were a lot more people on campus, the study was carried out around midterms.  Thus, it was even more difficult to schedule people into the same times.

Advertising online worked 100x better whether it was e-mailing certain mailing lists, posting on the psychology department’s list of surveys, or e-mailing previously interested people who’s schedule just didn’t work with ours for the first study versus posting paper posters around campus.

Getting people to think in the right mind frame was again an issue. I won’t go into this too much though it was interesting that I found students to have less problems with this than those who worked on campus.  I will not even begin to theorize why particularly since that was a trend over only 9 groups of participants.

Participants can be a great source. As we were doing another closed card sort, we had pre-set categories, but one of the participants in the first group came up with a much better categorization by adding a couple of categories, while removing one, creating less ambiguous categorization.

Analysis
As I didn’t write about this last time, I thought I’d write a little bit about analysis this time (I used the same method).  After gathering the results (simply by writing down the numbers of the sticky notes), I entered them into xSort, a free MAC card sort statistical program.  The program also allows sessions for participants to enter data, but is designed for individuals rather than groups, so I opted to put in the results myself and using it primarily for analysis.

Statistical Analysis
The program provided the standard distance table and cluster tree results.  The cluster tree options included single, average, and complete linkages.  From what I have read of the literature, it seems as if using average linkage trees is the most common and I did find that single linkage gave many more branches (and generally more groups too), whereas complete linkages gave few groups but also many more outliers when using a cut off in the standard range of 04.-0.6.  Average linkage gives a good balance between the two, but of course, I did not simply take the cluster tree and turn that into a new IA.

Subjective Analysis
During the study, I had also taken a lot of notes on labels that participants found problematic and their suggestions.  I also took notes on item categorization that participants found difficult to put into a single category, which was generally reflected in the cluster tree as well by tending to be the outliers or items that were not categorized.

Using the Results
Using the average link cluster tree, I used that as a basis for an IA. Many of the problematic labels identified in participants’ comments were renamed to better reflect the content that a link would point to, which also helped putting them into the right category.  One link we ended up never putting into a category and decided to work it into the design outside of the categories that we had created.  This version of the IA was then put forward as a draft which will hopefully see little change before the “final” version is made for the portal.

Inventory & Not Reinventing the Wheel to Create an IA

I had previously written about creating an IA basically through inventorying an existing site and using some basic assumptions to choose what to include.

I was recently tasked with creating another new section or portal to the website, but this time, I was not working off of an existing section.  Instead, I am creating a new section based on our needs and what other similar organizations have done.  So, this time I did it differently. In a sort of two step process:

  • inventory
  • looking at other websites

The websites I looked at were actually chosen by my boss because he knows which ones generally had the resources to do a lot of testing with their users and a good IT department with experienced staff members (or maybe it was just that he found these ones to be really good, probably both).  Looking at other websites helped create some initial categories as well as identify items that we might have missed in our inventory since there was no easy way to search for the content we needed.

Based on logical groupings and categories that other sites used, I created an initial IA to be used as part of the card sort study.

Launch of Help

So with the launch of help today, it will mean a redesigned section of the website. The key things we were going for:

  • clean & easy to read
  • consistent look & feel
  • standardizing some of the content
  • organization that makes sense to users
  • providing a design that gives a primary, secondary, and tertiary focus

This was the original main page, which was just a bunch of links which were not very well organized after the years of simply adding things compared to the new main page.


We took out the “Ask Us” from the main navigation bar and put it in a site wide side button, which many new sites are doing with feedback buttons. We also took out a mouse over menu from the main navigation bar that was a user guide type of page depending on the patron’s role (“Services for You”).

We moved those onto the Help page as well and linked to new versions with more or less the same content, but with some of it standardized and with a common look and tab navigation.

I like it and thinks it looks way better than before. Plus I think it’ll help our users find stuff!

EDIT: We received a lot of positive feedback! Yay!

WordPress annoyances

Warning: This is more of a rant than productive thought

maybe I’m just inexperienced, it probably doesn’t help that I don’t have admin access, but even asking coworkers whether something is possible seems to give me a “no”. Mind you, it’s not wordpress.org, but wordpress MU where my access is more or less restricted to the kinds of things I would be able to do on wordpress.com.

I haven’t figured out how or can’t do the following:

  • redirect pages (short of hardcoding it into the server)
  • make the frontpage not look for blog posts (and if there are none, not to display an error)
  • display subpages on a page (not in a navbar) short of manually doing it
  • change the width of a column (I know, I know, this is coded into the theme)
  • know exactly what it’s doing with my HTML code…. I’m stuck right now because I’m having a problem where the HTML code looks just fine but there’s something going wrong (thankfully a coworker is looking into that)

I’m sure I will be more and less frustrated with WP as I learn more about it.

When Wiki and HTML Formatting Collide

So I’ve been messing around with wiki coding since obviously I’ve been working on developing content on the wiki. One of the things I was trying to do was a hanging indent (here’s another more complex one where you don’t need to set a margin and documentation is better) in order to display citation examples properly. More than that, I wanted to offset the whole citation (i.e. add an indent) in order to make it stand out from the rest of the text.

Template Code (Hanging Indent)
Whether you look at the first or second template, they both modify the CSS in order to make the hanging indent. They essentially change two attributes:

margin-left:2em;
text-indent:-2em; (shifts the first line of a paragraph)

Now in order to indent a line or paragraph, there are usually a couple of ways to do it in wiki, but throw the hanging indent template into it and it didn’t always work out so well.

Add Wiki Code
Usually the best way to do a simple indent in wiki is using a colon, such as

: Indented text

However, I suspect that rather than adding to the margin, the wiki changes the margin for that text, and the hanging indent code overrides it. So, the result is that it does nothing.

Add HTML Code
The other option was to use the <blockquote> tag. As the blockquote does not interfere with the CSS styling, this had the intended effect except that just like in this post, if I use blockquote,

you get spacing before and after the blockquote as you would with a <p> tag

My Solution
Not a very elegant solution, and rather the brute force way, but I just ended up creating a template for citation examples that hard coded the extra margin. I suppose the other solution would have been to add an extra variable to the hanging indent template but I figured that would not be worth the trouble.

PDF2Wiki Conversion Comparison

So, some people may ask, why are you trying to convert PDF to Wiki? PDF is usually the last step in the process, so just use the original document. My response would naturally be, what if you don’t have the original document?

A Two-Step Process
Through my searching and reading on the topic, it seems there is no PDF2Wiki Converter. Every site that I have read explains converting the PDF to one of: DOC, RTF, HTML, XML first then to wiki format.

PDF2HTML
I tried a number of PDF to HTML programs, but none of them worked to my satisfaction. Most of them only converted simple formatting, such as bold and italics.  Adobe has an online conversion tool. It’s better than some of the others I’ve tried as it interprets lists and such. The resulting code is rather ugly and a lot of the code would need to be stripped before using a HTML to Wiki converter. See my previous post on HTML2Wiki for a couple of tools on tidying or stripping HTML code.

PDF2DOC
I found that a much better alternative was converting the PDF to a DOC/RTF file since it’s a lot simpler and some formatting might be lost, but you won’t have a lot of needless code that might mess up your wiki page. There are a lot of online tools that provide a PDF to DOC/RTF service, however, again, they only tend to do basic formatting.  Adobe Acrobat does a really good job, because it will change lists into formatted lists (instead of normal text).  The major downside of course is that Acrobat is a paid program though there is a 30-day trial.

Conclusion
I had a lot of problems in particular with PDF to HTML, so I thought PDF to DOC/RTF is simply. Honestly though, unless you have a PDF file which is really long and has a lot of simple formatting (bold, italics, etc.), if you cannot get your hands on Acrobat, then I suggest simply copy/paste (or alternatively save as a text file) and manually formatting it in the wiki’s editing box. Of course this depends on the wiki you’re using because ones that don’t have a toolbar to help you quickly format might be a bit of a pain. Someone please let me know if you have found a better method!

DOC2Wiki (Word2Wiki) Converters Comparison

So to continue on ways to convert existing documents to wiki code, next is formatted text documents, which is typically word DOC files, but may also be something like RTF files.

Most sites I found actually just instructed people to use a 2 step conversion. From Word to HTML and then to wiki code. While this may work, it’s much less efficient and I can imagine more things are lost in the process. Admittedly, the converters that I have found are all geared towards MediaWiki, so if you’re using a different wiki then these converters may not work so well. Nevertheless, MediaWiki provides a list of Word to Wiki converters the most basic of which does not seem to be specifically geared to MediaWiki.

OpenOffice Sun Wiki Publisher Plugin (MAC and Windows compatible, not sure about other platforms)
(the wiki converter is built-in, the publishing part of it is optional)
The downside of OpenOffice is that it does not always interpret word documents very well. Embedded images tend to turn into hex code (ex. ffd8ffe000104a46494600010201 etc.) and tables aren’t always interpreted correctly either. The one I tried turned into overlapping text. So, in part, the usefulness of the outputted wiki code will depend on how well OpenOffice has read the word DOC itself, but it should handle ODT and RTF just fine.

Word2MediaWikiPlus Macro (Windows Only)
Word is the better choice for documents that OpenOffice can’t seem to handle very well. There is also a Word2MediaWiki Macro which is easier to use, but does not convert tables or deal with images very well.

Special Characters
For the OpenOffice plugin, ‘special characters’ (used loosely here) sometimes turn into weird symbols or random special characters. As with the HTML converters from the last post, something like ’ (not straight apostrophe) gets changed into ‚Äô, or a bullet point (which isn’t recognized to be in a bulleted list) turns into ‚Ä¢.
The Word2MediaWikiPlus (W2MWP) converter is better at dealing with special characters. The macro will simply insert the character as is and at times put a nowiki tag around it, but regardless, it displays just fine.

Text Boxes
For some reason, the W2MWP plugin turns text boxes into a single cell table and then repeats the same text again as regular text (not inside a table). The OpenOffice plugin strips the text of formatting and leaves it as regular text in the wiki output.

Tables
When tables are interpreted correctly, I think the OpenOffice plugin does a better job overall. The W2MWP macro is better at keeping formatting, such as colours and border style (below right), but OpenOffice one seems to interpret things inside a table better, such as type of lists (below left). (It’s supposed to be a bulleted list, not a numbered list.)

Needs Good Original Document Formatting
In both cases, the usefulness of the wiki code will depend on how well the original document was formatted. For example, in one of the documents I tested, a number of the number and bullet lists were not formatted as such, but instead, numbers and bullets were just manually added. In both plugins, they were considered to be regular text with a ‘special’ character or number at the beginning of it.

Conclusion
Whether the Word2Wiki or the OpenOffice plugin is better depends on your priorities. OpenOffice seems to interpret lists and text boxes better, and doing a replace all for characters that weren’t interpreted properly is a pretty quick step. W2MWP is better at keeping formatting and interpreting all characters. So, if you like the way your document looks and you want to keep it that way, use the W2MWP macro.  The big downside of course is that it doesn’t work on MACs (which I’m using right now, yay for VMware).  Nevertheless, my conclusion is that the DOC2Wiki Converters are useful, but may not be the optimal solution depending on how much you’re willing to install and play around with. And if the document isn’t formatted like it should be, then manual wiki formatting might be the way to go.

HTML2Wiki Converter Comparison

So, for the past little while on and off, I’ve been looking for and playing around with HTML to Wiki Converters to see which one works best. Most of the ones I’ve found are online and most of them seem to be based on a Perl script created by David Iberri, who provides a web interface as well.

HTML2WIKI
David Iberri has provided a running web interface version for his script for a lot of different wiki dialects. However, I’ve only tested the MediaWiki version for the purposes of my project.  I really like the “Fetch from URL” feature which is not available on many others.

berliOS’ HTML2Wiki
Interestingly, I found what looks to be the exact same converter on another site, but it gives me slightly different results. (see below)

Seapine’s HTML to Wiki
The one is really good for basic things and even though it does not have a “Fetch from URL” feature, you can easily copy/paste.  However, this converter frequently broke for me when dealing with whole pages because it seemed to stop working when it faced something that it didn’t quite recognize.

Batch/Site HTML to MediaWiki converter
I have not actually tried this one, but I thought it might be a useful resource for later and for other people. This uses the same Perl script in combination with MediaWiki’s PHP importing scripts.

Comparison between HTML2Wiki and the berliOS version
General Text
Neither deals with ’ (the non-straight apostrophe) very well for some reason, and I’m guessing it will have problems with some other characters as well. Currently, both give a � in place. However, if it’s always the same character in your wiki document, it’s easy enough to do a replace all.

Tables
Both seem to handle tables quite well and one as well as the other, though sometimes the Iberri one seems to forget to put the first line of the table code on a new line, which of course, means the table fails to work.

Links
I would say that overall I like the berliOS version better for links because it can recognize anchor links, whereas the Iberri one will display text. For example (berliOS):

[#reserve Finding Articles on Course Reserve].

The Iberri one does a better job at “oh my god i don’t understand this” by simply stripping the HTML and leaving text. The berliOS one will try to interpret it and end up with odd things at times.  However, I think it’s pretty understandable that it doesn’t handle mouse over boxes very well especially when the original script to do that is CSS and not a part of the HTML tag. For example (berliOS):

You CAN find hundreds of thousands of articles through the UBC Library Web. more »
UBC Library subscribes to tens of thousands of magazines, journals and newspapers, in print and in full text online.
The UBC Library Catalogue DOES NOT list individual articles by topic. more »
To search for articles by topic, you need to start your search in an index or database. (Instructions follow.) Like the catalogues of most libraries in the world, UBC Library�s catalogue does not contain a listing for each article in each journal in its collection.
Search engines like Google DO NOT retrieve most academic articles. But… more »
”’Google Scholar (Beta)”’ has begun to reach some academic journals and online archives, but for now, Indexes and Databases are the most complete searchable lists of articles.
Most academic and publicly-funded researchers publish the results of their research in scholarly journals or in online archives, which search engines don�t reach. Most popular magazines do not provide their content for free on the Web.
Newspaper articles have a different search guide (right here).

Overall
So overall, I like the berliOS one better because it recognizes more elements, but it’s easier to screw things up with it. So I would say the Iberri one is easier to use since it generally just strips what it doesn’t understand.

Strip/Tidy HTML
On a related footnote-sort note, after converting to wiki code, if there is a lot of HTML code left that seems to be messing up the wiki page, you can try stripping or ‘tidying’ the HTML code. HTML Tidy tries to make the HTML conform to current HTML standards, but depending on how the page is done, it might start creating CSS which obviously wiki pages don’t understand, so the strip HTML function may work better.
Zubrag’s Strip HTML online tool
HTML Tidy