Overview of Product Edit

The business card creator lets customers customize the look of their business card with an in-browser editor. We focused on the first screen of the wizard, which allows users to design the back of a business card with a stylized piece of text. The parameters given to users are font, color, sizing, background image, position and rotation.

Description of User Interaction Edit

To start out the user must first enter the text they wants to stylize. Once the text is chosen it appears in the default style settings in the style editor.

In the editing area there are various options for the user:

  • On the top left there is a color palate
  • On the bottom left is the background image picker
  • On the right are various font options
  • Just below the card preview is:
    • Zoom in/out options
    • Color inversion (switching the background and foreground colors)
    • Rotate left/right options

As each option is chosen the result is immediately reflected in the card preview area (with some latency if it requires a server call, this is indicated to the user by a loading overlay). All customization except position changes happen with single button pushes. Position changes are handled by clicking and dragging directly in the card preview area, this always has zero latency. Implementation details

Architecture and Implementation Edit

The bulk of the Javascript code invoked following user actions in the card editing area of the page is encapsulated by an instance of the MooTextomatic class. For example, a click by the user on a pattern p results in a call to oMooTextomatic.setPattern(p). This object also encapsulates most of the calls to the external Javascript frameworks used by the website, most notably the Scriptaculous library.

The state of the business card currently being edited is stored in the web page itself: the pattern selector, for example, is implemented as a radio-button in the HTML, and the getPattern() method in MooTextomatic actually looks up the currently selected pattern through the DOM. This is an interesting choice; it would seem more convenient to store the state in variables in the Javascript code. This way, however, the state is only in one place with the trade-off of higher look-up cost.

Client-side functionality Edit

Two consequences of user action are treated entirely client-side: initial display of a new displayed background color for the card, and moving the text around on the card.

When the user selects a new color for the card, the client makes a call to the server to render the card image in the new color. However, it also immediately displays the new color. It does this by removing the previous card image, and setting the background color of the card display area to the new color through the DOM. This makes the color selection tool seem more responsive.

When the user clicks on the card image and drags, the text appears to move around with the cursor inside a business card sized box. In fact, the actual card image is considerably larger than the portion of the card visible on the page (roughly twice as high and wide). When the user drags the card they are moving the entire card image, which results in a different portion of the image to show through the image mask. To allow the user to drag the image, MooTextomatic uses the Draggable class from the Scriptaculous library, which works in roughly the same way as the click-and-drag interaction seen in class. To achieve the image masking, the draggable image is inside a div whose css overflow property is set to hidden. This property tells the browser to clip from visibility any internal element inside the containing element that isn't within the bounds of the containing element.

Server calls Edit

All other user actions result in a server call, including rotating, zooming, and choosing a pattern or a font. The corresponding MooTextomatic code removes the currently displayed image, and makes a "Loading" text visible in the card display area for 0.4 seconds (using the javascript setTimeout function). The Javascript code calls the server for a new image, passing all the current card's state variables as parameters to the URL.

Of note here is that the new generated image is being fetched asynchronously, but not with the now standard XMLHttpRequest object. Instead the background URL property of the image div is changed by the javascript. This is change in the background URL property is handled automatically by the browser as with all other style properties. As a result this allows for asynchronous fetching of the image.

Impact of the Web Edit

Use of Web facilities Edit

The Moo business card designer makes innovative use of several web facilities:

  • It exploits image caching in browsers to avoid making unnecessary calls to the server while editing the card. Indeed, if the user changes the card back to a already seen configuration, then the browser will display the previously cached image without calling the server. This is possible because all of the state of the card is written in the image URL.
  • It leverages basic HTML formatting to perform (or at least give the illusion of) simple image editing tasks. For example, it uses the HTML background color attribute to change the color of the card.
  • It utilizes existing Web frameworks, namely the Scriptaculous and Prototype libraries.

Problems Edit

The primary difficulty which the Moo page tries to overcome is the lack of any image editing facilities in HTML or Javascript. As a consequence, most of the image processing is done on the server. This would not be necessary if the business card tool was built as a native application using a programming platform such as Java/Swing or Objective-C/Cocoa.

Discussion Edit

The interaction studied here is fairly easily generalizable to any task involving image editing and layout/design, in fact it is used in various similar editors throughout the site, as well as on other design sites such as Vistaprint , Zazzle and CleverBug. Almost all of the image processing is done server-side, which results in a rather jarring user experience given the latency in the client-server calls. This situation would be much improved if browsers and javascript had more built in image manipulation facilities. In the current state of the Web one would have to use a plugin like Flash to do this kind of processing client-side.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.