William Gill

MorningMail is a news & event aggregator, curration and distribution system. It is currently being tested and should go into production for the start of the Spring ’11 semester. I designed it to meet the following communication and community needs of Rensselaer:

Centralize news consumption without centralizing news production

The system’s administrators can pull news from any site or system with an RSS/ATOM feed, from on or off campus. This keeps the infrastructure flexible and allows integration with the current and future landscape without a need to alter it.

Increase the value of existing websites

Morningmail is a tool for curators – it is aggregates news and people chose which news to highlight. Each news story links back to its source’s home site. This helps drive traffic to existing websites and helps keep sites fresh. This model allows website owners to concentrate on producing good content. MorningMail takes care of distribution.

Allow multi-modal distribution

MorningMail allows information producers to generate content on their website and have it shared with the campus community via a daily email, the MorningMail website, RSS feeds, digital signage and mobile website and apps. Future hooks could be built to share news items on Facebook or other new technologies.

Every morning, all the stories tagged to be distributed on that day are sent in a single email. The curator may select an ‘importance’ level for each news story. The email leads with the most important stories on top. The email consists of a series of headlines (which link to the full story on the site that produced the story) and a short teaser.

When people ask what I do at work, I generally say, ‘drugs.’ One of the things I actually do is web development for mobile devices. My first project in this space was m.rpi.edu. The site was designed to meet the needs of visitors to campus.

Visitors don’t necessarily want a long term relationship which is why a mobile website was selected over an app (a second factor we wanted maximum platform independence which is achieved by developing for the web rather than for a device).

Where possible, mobile skins/templates were applied to existing information housed within CMSs. Some high-value content was manually moved to HTML pages built within the mobile template. The appearance of a cohesive environment was created by applying a standard design across multiple pre-existing sites and technologies.

A standard header, footer, css, and javascript elements for UI were applied to each template or skin. Beyond that, integrating each service was a custom operation.

Home page

A list of links. I learned that on touch screens, a list of hyperlinked text fails because thumbs have substantial surface area. While I tend to reject icons for UI, here they provide sufficient surface area for thumbs to navigate the site.

Events

JS/JSON client side widget that pulls event data from Bedework (enterprise calendar used by RPI). All of the mobile sites feature lists of alternating colors, which allow the items to be placed closer together than if they background were of the same color and indicate a large clickable area on which to navigate. Javascript is used to make the whole element clickable rather than just the text. This proves particularly useful with short blocks of text.

News

XSLT skin for a home-built XML based CMS.

Alerts

Server-Side-Include of an HTML snippet generated by the RPIAlert system.

My current goals include CMS-izing as many sites as possible. Every site being deployed includes a mobile and desktop theme. As the number of sites with mobile themes grows, m.rpi.edu may very well become obsolete.