BlachanLab

I don’t know about you, but I often find myself checking Wikipedia citations and notes either to read more on a subject or to simply check the authority of a source. I do this while reading and not after I’m done reading the article. This process involves clicking on those tiny bracketed citation numbers which plummet the viewport down to the references or footnotes section, highlighting the citation content and often bringing it to the top of the viewport. I say often and not always because the area beneath the desired citation may not be long enough to fully scroll the citation to the top of the viewport. As a result, you end up depending on the highlighting mechanism and/or the numbering to locate the citation.

Assuming the user wishes to check sources while reading an article, this method of locating citations within a Wikipedia article poses a couple of inconveniences:

1. Disrupting the user's flow: by shifting the screen downwards and suddenly to the references or footnotes section, the equivalent of navigating to a second page occurs and the user's focus is interrupted. Returning back to where the user left off requires clicking the back button or a tiny arrow preceding the citation content, or manually navigating back using the scrollbar.
2. Inconsistent placement of citation content: the desired default behavior of a page anchor is to bring a linked section of a page to the top of a viewport, but this could only happen if there is a sufficient area beneath the linked section to scroll it to the top of the viewport. As a result, the targeted citation content ends up positioned dependent on the length of the area beneath it, giving way to a slightly inconsistent user experience.

Suggested improvement

Instead of us heading down to the references or footnotes section, it should come up to us! I’m not saying that the footnotes or references sections should be eliminated in favor of in-page citations– no, they’re quite useful and, not to mention, required from any self-respecting research article. My solution simply introduces a tooltip, which contains the citation content and any associated links (which could be background-tabbed at the user’s leisure). This tooltip could be easily toggled on or off by clicking on any citation number or note-link in an article. This eliminates the need to travel downward in any given Wikipedia page and provides for a more efficient Wikipedia experience. Here’s an example of how this might look like:

Shown in the diagram is an example of what could happen when a user clicks on a citation number. In the example above, the user clicked on the first citation which brought up a tooltip containing the citation information and an assortment of relevant links. This way the user’s flow of reading isn’t disrupted and they may open any linked sources in new tabs and quickly return back to reading the article by clicking on the toggle again to hide the tooltip.

This isn’t exactly a revolutionary idea, but I’m just throwing it around to whom it may concern. This is one area where introducing some Ajax could be considered a non-intrusive enhancement and it could be made to, easily, degrade gracefully (not that this matters much anymore) by defaulting to the current behavior.

What is Mo3jam?

Mo3jam ( معجم ) is a user-generated dictionary of colloquial Arabic. Mo3jam is Arabic for lexicon or dictionary.

What?

It’s basically a website, where users can come in and share what they know about the spoken terms and expressions in the various dialects of Arabic.

Now I know, there have been multiple attempts in the past at documenting colloquial Arabic on the Web. From my initial research, most of this type of content can be found scattered around forum threads, blog posts, forwarded emails, and the occasional dialect-specific website. Mo3jam aims to address these issues, and create a central, multilingual knowledgebase of colloquial Arabic, with emphasis on usability and breadth. Anyone should be able to contribute, with no wiki-bureaucracy or red tape. Instead, quality should derive from consensus.

History Lesson

Like many of you, I always thought, why isn’t there a place like Urban Dictionary for Arabic? Thoughts like these floated in my head for a while when I graduated in June 2007, but I never acted on them until around August 2008. Initial research started then, and I registered the domain names around September. I laid out a basic framework and specification for the website, but then I placed the project on hold until March 2009. That’s when the real drama began.

For the past 4 months, I’ve been developing and designing Mo3jam to bring you a usable phase one running with basic features. What you see now on the website is a result of that effort. Most major dialects of Arabic are currently listed, with a few definitions created by me and a couple of friends. Now that I think about it, four months seems a bit long for the current feature list, but I’ve been juggling between this, a part-time job and other projects, so development took nearly double the time it required.

Benefits

1. No registration required.
2. You can define using Arabic (preferably), English, or French.
3. In the case you decided to join, creating an account is easy through Facebook Connect, or using the regular registration process.
4. If a term is already defined, you may still add your own definition. The best definitions bubble to the top through consensus on quality (via voting, and favorites).
5. A proper multilingual interface (Arabic and English are currently supported).
6. The website looks pretty, to my eyes at least.
7. Implements transliteration of Arabic in input fields using Yamli.
8. Audible pronunciation of terms.
9. The list of dialects is not fixed. The system is designed such that there may be multiple levels of dialects and sub-dialects. All you need to do is suggest that a dialect be added.
10. Get feedback on your definitions via a like/dislike and favorites system.
11. Many more to come.

I must iterate on the fact that this is a developmental version of the site. The feature-set is not complete and bugs may surface at any point. Things like user profiles, password retrieval, commenting, refined listing of definitions are all missing, but should be up pretty soon.

The design of the user interface is influenced by the following: Facebook, StackOverflow, Vimeo, UrbanDictionary, DeviantArt, Wufoo, YouTube, Apple, Google, and my past frustrations with Arabic websites.

If you feel that you want to participate, please do not hesitate to do so. The feeling is natural. Mo3jam thrives on your contributions, and your feedback is all but welcome.

Mo3jam is best viewed on the latest Firefox, Safari, or Chrome. If you must use Internet Explorer, then use version 8. Website is not viewable in IE 6, and I’m proud of that.

Let me take you on an adventure:

Spices of the East:

My entrails are set in flames

Toilet tragedy

A long while back Code Golf posted up the Saving Time challenge in which you were required to transform input representing a digital clock into an ASCII analog representation in as few key strokes as possible. Here were my solutions in both PHP and Python:

PHP: 234 characters

<?fscanf(STDIN,'%d:%d',$h,$m);$s=array_combine(str_split('0b1a29384756'),array_fill(0,12,'o'));$s[$h=dechex($h>11?$h-12:$h)]='h';$s[$m=dechex($m>59?0:$m/5)]=$h==$m?'x':'m';vprintf("%9s
%5s%8s

 %s%14s

%s%16s

 %s%14s

%5s%8s
%9s",$s)

Not exactly the most beautiful code. If there’s a shorter way of converting from decimal to hex I’d probably cut 10 more characters or so.

Python: 232 characters

h,m=[int(x) for x in raw_input().split(':')];s=dict(zip('0b1a29384756','o'*12))
h="%x"%(h,h-12)[h>11]
m="%x"%(m/5,0)[m>59]
s[h]='h';s[m]='mx'[h==m];print "%9s\n%5s%8s\n\n %s%14s\n\n%s%16s\n\n %s%14s\n\n%5s%8s\n%9s"%tuple(s.values())

The Python code is in no way exemplary as it’s mostly a translation of the PHP code. What I can’t fathom is how someone could possibly solve this problem in 134 characters in PHP, the way eyepopslikeamosquito did. That is insane my friend. Probably ran a Perl solution through PHP’s shell command functions.

This past week I noticed traffic increasing towards Shahi, so I thought I’d implement some enhancements I recently had in mind, now that the service is getting more attention on Twitter and blogs.

The update allows you to switch between image feeds right within the image panel so you don’t have to repeat the query more than once. It’s good for quickly checking which image feed is most relevant to the definition. Shahi is now also slightly more fault-tolerant, so if let’s say Flickr fails to return any pictures, Shahi will immediately switch to Google Image Search, and if that fails, finally attempt with Yahoo! Image Search.

Enjoy!