skip to main content

TAMU Webmaster's Blog


Information and insight from the A&M Webmasters

style

How to Get Your Event on the Home Page

A headline on the Texas A&M home page is usually seen by more than 25,000 people a day. So how can your department get a piece of that valuable traffic? Here are some of the criteria we use when choosing which campus events will be featured on the home page.

  1. You can’t win if you don’t play. We don’t write our own material. Every event on the home page comes from http://calendar.tamu.edu.
  2. Appeal to outsiders. The main purpose of our home page is to reach out to prospective students and their parents. If a 30-year-old two-percenter has trouble caring about the event’s headline, a Delaware senior deciding between Cornell and A&M will have even more trouble.
  3. Headlines should stand alone. They should make sense by themselves. As a whole, the headlines on the home page should communicate a strong, positive message about Texas A&M – even if a visitor doesn’t click on any of them.
  4. Create a wow. Every headline should cause readers to say, “I didn’t know anybody did that. At least, I never heard of that before. And to think that it’s all happening at Texas A&M University. They sure do amazing things there.” Even if they don’t understand how the technology works, they still may be impressed by what it does!
  5. Make them want to click on the headline. Don’t expect visitors to click on “Monthly Departmental Seminar” before they can find out that it features a famous researcher with a tantalizing topic. They won’t bother to click at all on such a vague headline, and they may never know why they should have. If you have a famous researcher with a tantalizing topic, put that information in the headline.
  6. Make your headlines unique. Of course, if you’re presenting a series of identical workshops or performances, the headlines on the calendar will repeat. Otherwise, put the recurring seminar series name in the Subtitle or Description field, and leave the Title field for the latest, current installment. For example, you can use the lecture title as the event title, or condense it down. If you don’t know the lecture title, use the speaker’s name.
  7. Use title case. That means capitalizing each word, except for articles, prepositions, conjunctions, and forms of “to be.” It keeps your headline from standing out like a sore thumb.

But the headline, though it should stand alone, is not the whole story.

  1. Use proper grammar and punctuation. No matter how interesting the event, substandard English does not represent the University well, and will not appear on the home page (unless we’re slipping at our job.)
  2. Inform, don’t promote. Events on the home page answer the basic questions of who, what, when, where, and why, and your article or listing needs to match that style. In truth, shameless promotion turns off any readers that you’re not targeting. That is, parents might want to read about a junior service project, but if the article begins with “Hey Juniors!” they may assume they’re not supposed to. And whenever you say, “Don’t miss it!!” you’re saying that you can’t think of enough good reasons not to.

Tags: , ,

Thursday, June 19th, 2014 Calendar No Comments

Mobile Web Development at Texas A&M

I think everybody in our industry pretty much knows the speed at which smart phones and tablet devices are being adopted by the public, and even becoming users’ first choice of how to browse the web. We have seen waves of new technology before, but the speed at which these devices are being adopted is something we have never seen before. By nature, higher ed is slow to react, and this is no exception. Many of us realize that something needs to be done to meet this new demand, but the decentralized nature of campus web development has left us without a uniform strategy. Marcomm, along with TAMU IT, the library, and a few others across campus, are working to change that.

When discussing mobile web delivery, there are three basic areas that need to be covered — native web apps, mobile web sites, and traditional web sites made mobily accessible.

Native Apps

We’re all familiar with native apps. We go to the Apple Store or Andriod Market and download them all the time. Whether it is games like Angry Birds or an information suite like TAMUMobile, these are self-contained programs written specifically for each device platform.

Apple has done an outstanding marketing job and made these things a ubiquitous part of everyday life. Everyone now assumes “there’s an app for that” and that in order to be hip, cool, and sexy you have to provide your mobile information on an app. When talking to departments across campus we see this ingrained response quite often…the first (and often only) thing they want to talk about is app development.

When looking at a campus mobile strategy, though, we need to step back a bit and look at how each piece fits into the overall offering. So, who really needs a native app, and when do they need one? To be honest, most organizations on campus probably don’t need one. The expense of building and maintaining separate apps doesn’t make sense for most departments. More importantly, though, most campus units just don’t have content that belongs in an app. Apps should be limited to application content rather than flat text-based content, and ideally should be something that requires the processing power or other capabilities of the device hardware itself (camera, GPS, etc.) While exceptions certainly exist, most of this type of content will be of wide enough use that it would be better to include within the university level TAMUMobile app suite.

Mobile Websites

Mobile websites are those which are specifically build for a mobile audience. These people have different content needs from those visiting normal websites. You must therefore not just design for a device that has different capabilities, you must design for a completely different user. The mobile user has different needs and expectations from a desktop user, give them the content they need. The user IS mobile, not just HOLDING one.

The legitimate case for a mobile website is probably far easier to make than for a native application. These websites might be web applications themselves, but will not rely on special hardware needs of the device. They will instead be features of content that users who are on-the-go are looking for. They are a perfect alternative, then, to a phone app when it comes to providing basic information through text content. It would be targeted information, though, and would probably be more focused and contain less that would your full web site.

Because of the nature of these websites, they will tend to be high profile and central to the business of the university. In order to maintain a common branding effort to all of these sites, a central mobile team is looking at providing a mobile framework that will work cross-platform and allow you wrap the content from your choice of development tools with a common university mobile style. Details will be released to the campus community once the process gets a little further along.

Making your Website Mobile

Making your website mobile is not the same thing as making a mobile website. While a mobile website features audience-specific text and organization, the mobile view of your traditional website focuses instead on simply making your full content easily viewable on a mobile device. Mobile websites are audience driven, mobile views are device driven. We do this through reactive, or adaptive design.

It many ways it would have perhaps been better to start with this topic because it is the one section that everyone really should implement. Given the proliferation of mobile devices, it is now becoming imperative that your content is viewable on them. We would not any longer dream of making a website that couldn’t be viewed on a Mac or on a particular browser. We should now think of mobile devices as being in that same category. We really should not be producing new websites that are not viewable and easily usable on mobile devices.

This development is relatively simple now, whether through the use of simple CSS media selectors or full blown frameworks like Foundation. A Google search will produce more articles and documentation than I can review. At Marcomm we have begun adopting this philosophy for all of our own websites, starting with the main university site. We are still experimenting with the techniques we want to use, but we are fully committed to the process.

Conclusion

I understand that many of us on campus want to jump on the mobile bandwagon, and all of us should be involved to some extent. It makes sense, though, to add mobile as an element of your overall web strategy rather than trying to shoe-horn your content into the mobile arena. If none of your web content is mobily accessible, the first thing you should do is start looking at how you can redesign your current website to include mobile friendly views. This works better when the design is incorporated from the ground up, but old sites can be retrofitted with the proper use of media queries in your style sheets. Also look and see if you have content that should be presented on a separate mobile website. Again, this should only be done when you are trying to reach a particular audience with is also mobile, but it is a great way of connecting your users quickly to the content that they need. Finally, if your content is something of campus-wide interest or which requires the use of device hardware, consider a native phone app. Marcomm, TAMU IT, and others across campus are moving together in this direction. Look for more information from each of us in the upcoming weeks.

Tags: , , , , , , ,

Wednesday, March 28th, 2012 Mobile Web 1 Comment

Life Without Modern Development Techniques

Most of us can parrot web development best practices until we’re blue in the face. Design with CSS, take advantage of inheritance, use semantic markup, separate design from content, etc. Last week we took on a new project that made the importance of these recommendations sink in – by stripping them all away.

Our department has several mass-email jobs that are sent out on a regular basis. Thus far they have all been standard plain-text messages. It has been decided, though, that we should make the move to putting them into a web template and sending out the message as HTML.

As I started pulling everything together one thing became immediately clear – as much as we bemoan the inconsistencies between web browsers, they don’t compare to the differences in how email clients render HTML code. In order to make the display work across even the most common clients you have to throw out the last five years of web development and go back to the basics. This means layer upon layer upon layer of nested tables, untold numbers of colspans and rowspans, style elements applied to every paragraph, and being careful to minimize the number of images and their file size.

After being neck-deep in these templates for a few days, with one more to go, I’ll never again take proper techniques and procedures for granted. It also means don’t bring me a tables-based design and ask for my honest appraisal of it… 🙂

Tags: , , ,

Monday, January 31st, 2011 HTML No Comments

Browser Support

Departments and offices on campus will frequently ask to consult with us whenever they begin a new redesign process (we love talking to you, please continue to do so.)  One of the most frequent questions that comes up, despite being a topic that has been rehashed a dozen times in the last two years, is which browsers have to be supported.

My answer usually surprises folks — “all of them.”  This is my attention grabber that then lets me make a point and go into a longer explanation of content, the levels of accessibility, usability,  “browser support,” and the differences between these terms.

As a public university we have an obligation to make our information available to everyone, and as a web professional I think we have a mandate to do the same.  So the informational content of the page should ideally be accessible no matter what user agent the visitor decides to use — the latest version of IE, Safari on iPhone, JAWS speech reader, lynx textual browser, or even Netscape 1.0.    All of these can render the basic HTML that delivers the content, so there is no reason the site design should be such that the information is not delivered.

Note that the above makes no reference to what the page looks like.  Indeed, on various user agents it will almost certainly look different, possibly even bad.  But the information is there and is available.  Only once this bar has been met should we get into the question of what most of us mean by browser support — those which we want the general appearance and experience to be the same.

This, then, limits us to browsers that support web standards plus those for which we are willing to make exceptions and add hacks… largely IE 6.  Analytics shows us that usage of IE 6 has finally fallen to a low enough percentage that we need no longer consider it mainstream.  Unfortunately it is still high enough that it can’t be ignored.

I don’t buy into the argument that a site has to look and act exactly the same for every visitor on every device.  Minor differences are expected as each rendering engine treats the base HTML and CSS slightly different.  So let’s extend that concept and go back to content accessibility – can we create an experience in IE 6 in which the content is delivered and the page looks OK?  Not perfect, not exactly what other browsers will see, but good enough to deliver your information and not create a negative experience or perception of our organization.  That can be done easily enough using IE conditional comments and a separate style sheet to overwrite and tweak the default style.

So, long answer to a short question.  “Do we have to support IE 6?”  Yes… so long as you understand that support doesn’t necessarily mean providing the same experience as modern browsers, it just means making sure those who insist on using it can still get your information and not be turned off by the process.

Tags: , , ,

Friday, January 29th, 2010 Browsers/Plug-ins No Comments

Categories

Archives