Jungledragon Blog

Eagle eyed JungleDragon followers may have noticed the little reputation chart on the user profile screenshots that I shared earlier:

To really appreciate this component, you have to see it *and hover it* in action. That’s why I cooked up a little demo site for you to try it (click to visit the demo site):

Like it? Read on…

The purpose of this chart is to show trend data, in this example concerning a user’s reputation. Each plot point in the chart concerns an event that led to a karma change, be it positive or negative. When you hover a plot point, you see the karma change, but also a summary of the event took place along with the date.

And, the very best thing about it is that is not Flash based! This is Javascript only.

How it’s made

This chart is not written as a generic component, so I will not detail every line of code. Still, I will give away some clues should you want to do a similar thing.

The main thing to know is that this chart relies on the Raphael javascript library. Raphael uses SVG rendering (or VML in the case of IE) to draw objects on a canvas. Raphael lets you interact with the vector objects using Javascript.

By sheer accident I ended up at this chart demo one day. I liked it a lot and decided to customize it to my needs. That was pretty tough actually, since the original demo’s code is not documented, slightly messy and pretty much hard coded. I changed several things:

• Scale transformation since the demo could only handle values between 0 and 100
• Customization of the grid and general look & feel
• Extra logic to differentiate between positive and negative plot points
• Custom placeholder and data parsing for detailed event information when you hover a plot point

The resulting chart, which you can see in the demo, works perfectly for my needs. Basically it works like this:

• The HTML on the page has a hidden table containing the data. The data is split into tfoot and tbody tags.
• The cells in the tbody tag contain the actual numbers which are used to draw the plot points
• The cells in the tfoot tag contains the event description that match with each plot point
• The script parses the table, builds up internal arrays for the data and renders the grid, chart and such
• Upon hovering a plot point, it will look up the details in the internal array and display it in the bottom placeholder.

There’s a whole lot of coordinate logic going on, but the essence of it all is simple.

Two final remarks:

• Although this demo should work fine in IE, it does show that IE’s javascript engine is slow compared to Chrome, Firefox and Safari. There are a lot more hickups in IE.
• If you are willing to dive into the code, you are free to take this demo and customize to your own needs. However, I would advise considering alternatives as well. For example, there is a dedicated Raphael javascript library for charting called gRaphael.

Do you like it?

In this post I will explain the JungleDragon button bar, which is a button bar that applies to an image. I will detail how it works, why it was designed that way and how it was made. Perhaps there is something you can reuse.

How it works

This is  what the button bar looks like below an image:

The button bar is a context menu of actions one can apply to the image above it. Each button has a number of states. For one, there is the invisible state. Perhaps silly to mention, but the button bar will only show a button when it is relevant. This can be based on the authorization of the user, but also the state of the image.

Next, there is the hover state, where a user hovers over a particular button:

There is also a disabled state, for example when a user has already applied the action. An extra explanation is given using a tooltip:

Finally, there is the active state. It looks similar to the hover state but the interaction is different. In this example, the user has clicked the image to toggle zoom mode. Although the zoom button was not clicked, it was activated indirectly:

Design considerations

There are many ways to design a button bar like this, so hereby I will explain my reasoning behind it. We web developers tend to default on standard icon sets such as Silk for our icons. As nicely as those icons look, I still decided to chose a different path, here’s why:

• I believe that content matters most, and that content should stand out, not icons. Perhaps this is a personal preference but I dislike how bright colorful icons curse with an otherwise consistent user interface style. especially when most of your audience will simply view content and not apply any action on it.
• Look at real world icons, such as traffic signs, airport signs and such and you will see that most of them are monochrome, using two colors with a high contrast for optimal legibility.
• Icons are ambiguous. A star icon could mean “rate this” or “add to favourites”. What is the agreed icon for a “history”? To be sure that the user understands the icon, it makes sense to supplement it with text.
• Standard icons sets typically do not have different states (normal, hover, disabled, active).

All in all I believe I had good reasons to go the custom path, so let’s see how it was done.

How it’s made

It’s simple to create a button bar like this, but there’s some interesting clues to share nevertheless…

For one, I did not create the icon illustrations myself. I grabbed them from the jQuery UI theme page. For each icon that I needed, I cut out just the icon (not the box around it) and paste it into my button box template in Photoshop. If that page did not provide the icon I needed, I would use an icon search engine for my needs.

Next, the text. It would be ideal if we could make the icon button text part of the HTML. At the same time, we do not want it to take up too much space. Unfortunately, browsers suck at rendering fonts at such a small size. Therefore, the texts are part of the icon images. In order to make the texts look as clear and crisp as they do at such a small font size, we need to use a pixel font. I used PF Arma Five for it. It is important to realize that pixel fonts are designed for one size only, in this case 8px. Therefore, do not apply any effects on it in Photoshop and do not change the font size.

Finally, integrating the result into the web front-end. The default way would be to simply cut out the images and refer to them in our web pages. However, given the number of buttons and their states, this could easily lead to a dozen or more HTTP requests. An additional problem is that when we do not preload all states, the user may have to wait for an image to be loaded when they hover a button.

This is easily avoided by using a spriting technique. Instead of loading dozens of icon images, I only load one:

Next, I use CSS background image positioning to show the correct part of the icon. The result is a single HTTP request for the entire button bar and no load times for the hover states. If you are new to this technique, I can recommend this introduction.

Main buttons

Whilst on the subject of buttons, I want to share the improved look of the action buttons I use in forms:

It is created using this technique. I love the result. What’s also nice is that the color is controlled in CSS. The shadows and shine effect are an overlay. It also looks the same in Internet Explorer, which is notoriously bad in button rendering. However, there are downsides to this technique:

• The markup is not pure. It uses a href links instead of input or button HTML elements. Unfortunately, there is no other way to make a button look this nice in IE.
• One consequence of not using a normal submit button is that submit behavior that you rely on will stop working. For one, you will have to use Javascript to submit the form upon clicking the link. If Javascript is disabled, you’re out of luck.
• Another consequence is that hitting ENTER to submit a form will not work. A cheap trick to work around this is to include a input button or image of type submit, and make it invisible through styling.

I’m still in doubt about this one. It feels dirty, even though JungleDragon needs Javascript to work anyway. Still, the result is beautiful. Once again it is Internet Explorer who makes the web miserable.

So, what do you think about my approach towards buttons? Do my design considerations make sense?

You would think that since JungleDragon is about sharing images, the majority of my development work is in images. That’s not true though, the vast majority of my development work for JungleDragon evolves around users. Their account. Their content. Their interactions. Their friends. Their reputation.

The whole social glue of JungleDragon is scattered across the application, but for now I will focus on the user profile part. The user profile is the place where everything concerning a single user comes together. What I will show you in this screenshot tour is already the third version of how I implemented user profiles. I threw out many hours of work twice in a row because I was not satisfied with the result. Now I am, although some polishment still remains.

Your own profile

This is what your own profile looks like when you are logged in. Click to enlarge:

As you can see, it has somewhat of a portal design style. We’re currently looking at the home page of our own user profile, yet there are many other pages which can be accessed using the tabs. The left column shows the tab specific content. The right column is the user context, it summarizes basic data about the user and stays consistent no matter which tab you click. So all in all we have a dynamic left column, a static right column, and tabs to move between specific sections of the user profile.

User activity streams

Now, let’s talk about the most powerful aspect of user profiles in JungleDragon: activity streams. JungleDragon records all activity around any user, both active activities (you uploading an image, you commenting, voting, etc) and passive activities (another user voting on your image or comment, another user moderating your image, etc).

The benefit of having all this information is that we can then show an activity stream of a user as can be seen in the screenshot above. An activity stream is similar to a user profile on Twitter, it shows a list of user activities, newest first. With this in place, one can instantly see what a user or friend is up to. No need to click through all tabs to see if anything happened. Cool.

What I think is even more interesting is the way in which it is implemented. A few notable details:

• The karma graph. This is a chart like control that shows the reputation trend of this user. You have to see it to believe it really, you’d think it is Flash but it is plain Javascript with all kinds of cool hover tricks. In essence, this is a picture of how this user is doing, reputation wise.
• Activity context. A system like twitter only has one user event: posting a message, but JungleDragon has 20 user events. So how do you distinguish between these event types? Context is the answer. The image that you see on the left of each activity row represents the context. If you do something around a specific image, it will show that image, if you friend someone, it will show that user’s icon, if you get promoted to a higher class, it will show the new class image. And so on…
• The middle column of an activity row describes the event that took place along with links to the object or users in context, if applicable.
• The right column of an activity row show the karma reward associated with the event, consistent with the plot points in the chart.

All in all I think this makes for quite a rich activity stream. Important are also the differences in what you see. If you look at your own profile, you will see all active and passive events evolving around you. However, if you view a profile of another user, you only see their active events (click to enlarge):

Notice also that the karma chart is not visible for other users, for reasons too long to explain here.

Editing your profile

Let’s take a little break from activity streams and see how a user can edit their profile. The last tab, showing the administration icon toggles the user profile into edit mode. Alternatively, the “Manage your account” block can be used. Click to enlarge:

Profile editing is split into optimized screens for each task in order to keep it friendly. That’s why there are seperate screens for changing your avatar, email and password. The main profile edit screen is shown above. There is not much to tell about this screen other than some usability best practices I tried to follow:

• Large labels and input boxes
• Clear seperation between main action or cancelling
• Each field on a new line to increase readability (exception is the birthdate field, which is a composed field)
• Non-intrusive: only your username is required

An insignificant, but subtle little detail is what happens when you step back out of edit mode. Your “About” block will automatically assemble a natural language sentence that summarizes who you are:

See the sentence in light gray. Since none of the fields are required, it will list what it knows about you.

None of these details are designed by accident or because I think they are just cool. The whole user profile design is designed around how we socialize in real life:

• Who are you (user details)
• How are you (reputation)
• What do you do (activity stream)
• Who are your friends?

Friends

JungleDragon allows you to friend other users and on the “friends” tab of a user profile you can see who they are (click to enlarge):

Here you can see who your friends are. You can also delete individual friends or visit their profiles. Notice the little filter on top which allows you to sort the list of friends in different ways. Cute, but by far the most powerful aspect of the friends feature is the green button named “View friend activity” (click to enlarge):

This works just like the user activity streams we talked about before with two important differences:

• It is a stream that consists of multiple users, not just one. In a single screen you can see what your friends are up to
• Since this concerns multiple users, the left image shows the friend concerned, and the right image shows the context

Should I ever build a group function in JungleDragon, where a user can create a group of interest and others can join, I can easily make a group activity stream.

Tags

Through viewing a user tags, you can quickly see their interests (click to enlarge):

This screen does what it needs to do: show the list of tags, different ways to sort them, and of course a way to see how many images are in a tag.

Comments

From a user profile, one can see an overview of all comments made by that user:

A nice little touch is that it shows the image and image title to indicate the context of the comment. Other than that, I do not feel this is a really useful feature because most comments are part of a discussion with others. Nevertheless, it could be useful to see if a user makes meaningful comments or the opposite.

Community browsing

Most of the time, you will end up at a user’s profile through context. You see a beautiful image and notice that it was user “McCrock” who uploaded it. You click through to see what else he got. However, some users may also actively want to browse the community. For that, there is the Users screen (click to enlarge):

This single screen is powerful, it basically gives you access to the entire community:

• Sort and browse through users by popularity, name, registration age
• Type-ahead Ajax search if you know (part of) a user’s name
• The list of your friends on the right

Todo

• You may have noticed how I skipped over the “Images” and “Favorites” tabs in this blog post. The reason is that showing lists of images is still something I need to work on. It is a very important part of JungleDragon that I should implement right, and then reuse it at the many places where it is applicable.
• Users can use tags for their uploaded content, but they can also favorite tags. This is not yet implemented at the user profile level
• Subscribing. Both RSS and email subscriptions are not yet implemented in JungleDragon, but they will be important particularly for activity streams.

One final consideration that I have regarding user profiles is about user activity streams. I think the implementation is sophisticated, rich and somewhat original, but worry about its verbosity. It would be cool if a user can select which events to show on user profiles, but that would increase complexity for both the user and me, as an implementer.

I hope you made it all the way through this post, if so, I admire your courage. Implementing user profiles was hard. It was a ton of work, I changed my mind a lot and there are quite some complexities to it, more than you would think. I think I finally nailed it for the most part, but would like to know if you agree?

Note: I will tell you about how I created the karma chart in a dedicated blog post.

My project JungleDragon is about user-generated content, images of nature to be specific. Therefore, users need to be able to upload these images. This functionality I have completed about a year ago already, since without it, it is hard to test anything at all. The upload process is quite heavy and complex, the following sequence of events are occuring in real time:

• User selects file to upload
• File is transfered to the JungleDragon web server
• A process cuts out five additional formats (thumbs and such)
• The resulting 6 files are transferred to Amazon S3, their permanent storage location
• Database records are updated (image table, imagefile table, tags table and user karma table)
• The user is redirected to the newly uploaded image

Last week I was using the upload form to upload the following test image (click to enlarge):

This concerns a 1.6MB jpeg with a very high resolution of 3872 x 2592 pixels. I measured the total upload process at 24 seconds, which is awfully slow given that my client machine is on the same home network as my development server. Painful as it was, I had to do some major heart surgery to improve this.

Scheduled Amazon S3 transfer

My first assumption about the upload time was that the realtime transfer of the six files to Amazon S3 would take a lot of time. In essence we’re doing a double upload, one to the web server, and then one to the Amazon S3 server.

I decided to move the S3 transfer logic to a scheduled process, a cron job in Linux terms. The cron job looks in the database for image files that are not yet transferred (transferred = 0), makes the transfer, and then updates the image location in the database.

This brings good news: the total upload time decreased by 11 seconds, making it almost twice as fast. What’s also nice is that there is no user impact. As long as the images are not yet transferred to S3, the local images are served. Users can directly work with the uploaded image in all sizes. Once the S3 transfer is made, the image will be served from Amazon S3 but the user will not be able to tell.

Smarter resizing

It was nice to see the upload time of the test image go down from 24 seconds to 13 seconds, but it is still not good enough. I had the false assumption that the remaining 11 seconds would primarily be spent on the upload transfer. In reality, something else was wrong. My resizing logic was not efficient. This is what I did:

• Resize from original size to large size
• Resize from original size to medium size
• Resize from original size to thumbnail size
• Etc…

This way, each resize action took about 2 seconds. I changed this into a smarter way of resizing:

• Resize from original size to large size
• Resize from large size to medium size
• Resize from medium size to thumbnail size
• Etc…

This way, the total resize duration went down to about 2 seconds, and the total upload duration to about 3 seconds!

Image compression

Another small but important improvement that I made is to compress images while resizing. By compressing to 90%, the image file size goes down by a factor between 2 and 3. This is an important saving since my Amazon bill is based upon disk space and transfer bandwidth. In other words, this saves me money.

User experience

I also made two important changes to the user experience of the upload form:

• The file input control is styled. It looks consistent with the rest of the design. This is something that cannot be done using CSS only.
• There is now a fake upload progress bar (animated gif) whilst the user waits for the upload. It may feel like cheating, but studies suggest that users experience wait times as shorter when they see something actually happening

Image engine control

Several settings have been added to my back-end code to configure the “image engine”. With a few constants I can control:

• Where images are stored (local only, s3 only or local_s3, which is a failover mode)
• Whether images are transfered to s3 directly or scheduled
• In what quality rate to store the images

Quite powerful when you think of it.

The result

The result of these improvements can be seen in this video. In the video I first upload the high resolution image, and then an image of which the resolution is optimized for the web.

You may want to view this enlarged in HD in order to follow what it happening. You should see that the upload experience is quite snappy now.

Conclusion

Making these improvements was painful and took quite some long nights but the results are there:

• The total upload duration is speed up by a factor 8
• The resulting file size is between 30% and 50% lower than before (depending on the quality rate)
• The form looks better and gives better feedback
• I can easily control key aspects of the image engine during runtime

For me, I learned two lessons as a result of this improvement battle:

• Don’t assume. Know. Measure and know how things work at the lowest level.
• Persist. Do not give up until you have the result you want.

I’m absolutely thrilled with this improvement. I can’t stop uploading images to JungleDragon

In this post I will demonstrate the two ways in which you can zoom into images uploaded to JungleDragon.

First, a little explanation of what happens when you upload a new image to JungleDragon:

• Original image gets uploaded to the JungleDragon web server
• A script runs to intelligently resize the image to different formats:
  • Square: Tiny square thumb
  • Small: Small thumb with aspect ratio respected
  • Medium: Normal size used to display image on image page
  • Large: As the word says, larger than medium
  • Original: The untouched, original format
• The resulting images are transferred into Amazon S3
• Exif data is retrieved from the original
• Database records are created for the new image (one main image entry and multiple imagefile entries). When applicable, tag records are created too. Finally, karma is rewarded to the user and their karmalog is updated.

With this in mind, let’s have a look at how to zoom in JungleDragon:

View image formats

The simple, static kind of way to look at different image sizes is to hit the button “View sizes” in the image button bar:

This will open the “View Sizes” page (click to enlarge):

From this page, one can select the size to view using the tabs. Additional options include a download button (that downloads the size on screen) and an embed panel, which spits out code to embed the current image size on an external website. Comments, votes, tags and all other controls normally associated with an image are stripped from this page to keep it simple.

Image live zoom

The second way to zoom into an image is to use the live zoom function. This short video demonstrates the effect:

This is what happens in the video:

• User has a normal image page open (displaying the medium sized format)
• User clicks on the image
• Large image is loaded in the background (takes about 0.5 sec in the video so hard to see)
• User hovers over portions of the image and sees increased detail as taken from the larger size image
• User hovers out of the image and sees the original, medium sizes image again

How it’s made

Perhaps a little bit of a gimmick, but I find it a nice, unobtrusive effect, since users actually have to click to activate zoom mode. You are probably wondering how this is implemented. Here’s how:

• Download MagicZoom (license is only 29£)
• Install the JS library into your project and refer to it on your page
• Install the CSS file into your project (or integrate the rules into your main CSS file)

Next, create the appropriate markup on your page. This will consist  of a normal image tag which points to your medium sized image, surrounded by a “a href” which points to your larger image size. To set the options of the zoom plugin, the rel attribute of the a tag is used:

<a href="address to your large image"
class="MagicZoom"  rel="click-to-initialize:true;click-to-activate:true;
zoom-position:inner;zoom-fade:true;">
<img src="address to your smaller image" />
</a>

As you can see, I’m using an inner zoom mode, which overlays the original image with the zoomed one. There are many ways to customize the behavior though. A plugin that just works, I love it. Do you?