Design choices for the twitter public timeline app.

Below this line of text you should see:

  • An example tweet display.
  • HTML for the app container and the DHTML for one tweet.
  • The CSS file associated with the app.
  • The TPT (tpt.js) start-up options.
  • Explanations of the design choices made for the entire application.

The Tweet Display:

The HTML Structure:

The CSS (tpt.css) Structure:

The TPT (tpt.js) Start-Up Options:

Future-Proofing the Design:

  1. Design the app to be modular.
  2. Design the app to be easily positioned and styled
  3. Design the app to be easily configurable to laymen, as well as programmers.
  4. Design the app to be easily upgraded with new functionality.

Considerations, the design as a whole:

  One thing that will become apparent as you study the design is that each element has a unique id attribute. Each DHTML id is of the form: {app}-{type}-{ID}, where:
  1. {app} represents the application that created the element.
  2. {type} represents the type/function of the element.
  3. {ID} represents the unique ID differentiating it from all others of its app-type combo. ( in the case of this app, it's the tweet id )

  The unique ids will allow us to target each individual element of the running app and add additional fine-grained functionality later on, if desired.

  Another design characteristic is that each DHTML element is assigned exactly one CSS class from the tpt.css file even if it's also using classes from the general site's CSS. The CSS classes can be arbitrarily named, but I generally follow the app-type paradigm to make the singular connection between element and class obvious. In the case of some CSS classes like "tptImageLink" or "tptText" with (now) empty CSS declarations, this can seem superfluous at 1st glance.
  However, as a general design principal, I find it advantageous to allow a designer to add new styling later, in a fine-grained way, by only editing the app's CSS file. This allows us full control over the look and feel of each type of element in the tweet display. Even the name(s) of the CSS class(es) to assign to each element are defined and passed to the app as options during start-up, future-proofing those as well.

Considerations, line by line:

  • HTML, Line #1: <DIV id="tptWrapper" ... >

  This is the element the app uses as a container when inserting the dynamically generated DHTML tweets for display. I decided early on that this element would be a "container" for all the output generated by the app ( a modular approach that has paid dividends in the past ).
  By choosing to statically define the containing element in the HTML source and pass its ID to the JavaScript app, we've made it easy to change not only the display location, but also the containing element type itself. We could easily locate it in a sidebar, for instance, or even change the containing element to some other type if needed, all while working only in the HTML file. All we need to do to retain backward-compatibility is to keep the id="tptWrapper" attribute.
  • HTML, Line #3: ( new tweets are inserted here )

  New tweets are inserted as the 1st child of the surrounding container, providing an aesthetically pleasing display of tweets moving down the page, with the most recent always at the top.
  • HTML, Line #5: <DIV id="tpt-{ID}" ... >

  This is the outermost element of the tweet itself. Another containing element, that allows us to control the look and feel for the entire tweet as a unit via CSS. By choosing to wrap each tweet in its own element, we've made it easy to change the look or add new eye-candy like fade-ins, animations, or even drag/drop functionality. The unique ID allows us to easily add new functionality that targets a tweet's display later on.
  • HTML, Line #8: <DIV id="tpt-topRow-{ID}" ... >

  This element defines a top row container, allowing for the addition of elements to be visually separated from the rest of the tweets display. In this case it only contains the tweeter's name with a link to their twitter page, but I designed it this way because I imagined later adding icons and links to twitter functionality and floating them to the right-side of that row. The open-ended design would allow this if I ever get around to it.
  • HTML, Line #11: <A id="tpt-name-{ID}" ... >

  This element is the anchor link to the tweeter's twitter page wrapping the tweeter's name. No special considerations here, beyond giving it a unique (per user) target to open it in a named window or tab.
  • HTML, Line #18: <A id="tpt-image-link-{ID}" ... >

  This element is the anchor link to the tweeter's twitter page wrapping the tweeter's image icon. Functional considerations include giving it a unique (per user) target to open it in a named window or tab.
  • HTML, Line #23: <IMG id="tpt-img-{ID}" ... >

  This element is the tweeter's image icon. Visual considerations were that it would be a fixed size and float to the left of the tweet text like an article photo.
  • HTML, Line #28: <SPAN id="tpt-text-{ID}" ... >

  This element only contains the linked tweet itself, but I designed it this way because I imagined later adding additional data and links to twitter functionality and floating them to the right-side or bottom of that area. The open-ended design would allow this if I ever get around to it.
  • HTML, Line #31: <A id="tpt-tweet-link-{ID}" ... >

  This element is the anchor link to the tweet page wrapping the tweet text. Functional considerations include giving it a unique (per user) target to open it in a named window or tab.

In Conclusion:


  I really enjoyed designing and coding the application. I was able to learn new things along the way, including my first encounter with the twitter API, and my first encounter with an obscure bug in IE8 DOM manipulation that prevented me from using <P> tags in the tweet layout. It involved quite a bit of research, and a lot of debugging, but was worth encountering, just for the feeling of satisfaction I got when I found and fixed the "problem".

  Initially, I thought about parsing the tweet using regex and creating hyperlinks in the tweet display to all the embedded URLs, tweet targets, and other information provided in the twitter data. It all seemed rather nifty at 1st glance, but at some point it all started feeling like over-engineering and feature creep. Since clicking the link will currently take the user directly to the twitter page that does all that, I decided to leave most of the extras I was dreaming about as an exercise for another day.

  One unrequested feature that did make it into the final product was the 3 second delay between tweet displays. The original prototype did exactly as instructed: It would load all the tweets into the page, then do it all over again 60 seconds later. On the plus side it was simple to manage, but on the negative side I just didn't like the display action... In plain words, it was sudden, jumpy, and just seemed ugly.

  20 tweets every 60 seconds isn't exactly hard math to figure out. My second iteration involved refactoring around a revised timing mechanism which slowly displayed a feed full of tweets during the same 60 second time interval. Now the tweets seemed to stream in live, and it became hard to judge when an old feed had been depleted and a new feed had begun. This one small aesthetically pleasing change in the display mechanism seemed to make all the difference in the world.
 

A virtual Jeff Allen


Name: Jeff Allen

Occupation: Software Engineer

Experience: 10+ years

My life-long love affair with ones, zeros, and programming in general began in the local video arcade. I soon transitioned to learning BASIC at age 13 on a Apple II+. It wasn't long before I was creating my own video games and mastering the arcane incantations of 6502 assembly instructions.

Recently I acquired 10 years experience engineering both front-end and back-end web software using a multitude of web technologies.

My passion is developing rich internet applications in multiple languages and locales using client-side JavaScript libraries and technologies like Ajax, JSON, HTML5, CSS3, I18N, L10N and others.

Some of my strong suits: MooTools, JavaScript, Ajax, JSON, XML, XHTML, CSS, PHP, JAVA, SQL, and Internationalization & Localization.

Currently I live with my lovely wife Jill and 4 cats of questionable heredity in western Ohio.

Feel free to explore this website, and browse a selection of my work here in my portfolio.