skip to main content

TAMU Webmaster's Blog

Information and insight from the A&M Webmasters

Style Guide


Solr is an open source enterprise search platform, written in Java, from the Apache Lucene project. Its major features include full-text search, hit highlighting, faceted search, real-time indexing, dynamic clustering, database integration, NoSQL features and rich document (e.g., Word, PDF) handling. Providing distributed search and index replication, Solr is designed for scalability and fault tolerance.

Databases and Solr have complementary strengths and weaknesses. SQL supports very simple wildcard-based text search with some simple normalization like matching upper case to lower case. The problem is that these are full table scans. In Solr all searchable words are stored in an “inverse index”, which searches orders of magnitude faster.

Solr exposes industry standard HTTP REST-like APIs with both XML and JSON support, and will integrate with any system or programming language supporting these standards. For ease of use there are also client libraries available for Java, C#, PHP, Python, Ruby and most other popular programming languages.





Wednesday, November 16th, 2016 Site Architecture, Systems, Web Content No Comments

New Websites and Where to Start

Last week we mentioned to Brand Council that we are beginning to look at retooling the university website.  Kendra and several others responded that they would also be starting redesigns soon and asked that we post some of our research regarding browser sizes, best practices, and such.

First of all, read through the Web Style Guide on this site.  We put this together as part of the redesign we did on the site a few years ago, and most of it is still valid. Also take advantage of the Brand Guide, local copies of the HTML and CSS validators, and the web accessibility website.

Page Layout

From a purely philosophical standpoint fluid or elastic layouts are preferable to static, fixed-width, designs. That being said, fixed-width is easier both to code and to design. We were stubborn with the last design and created a relative-width page out of principle, but I’ve never been happy with that floating square next to the Flash spotlight. This time we are going to bite the bullet and go back to a fixed-width layout so that we don’t get that random padding.

Page Width

Since we are decided on fixed width, the next question was to decide on what width to use. As conservative as I am on these matters, even I will concede that the days of coding to 600×800 are over. Our analytics show that the most common resolution is 1280×800, but with 1024×768 still making up 20% of the traffic. We are therefore taking that as our base, minus a bit to account for padding and the scroll bar.

HTML Specification

We will be using xhtml 1.0 strict for our templates. I like the clean formatting that the strict specification forces upon developers. It makes for better, more valid, and more accessible code. HTML 4 is in my opinion too old and leads to too sloppy of a code to be adequate. While I am excited about the semantic structure that HTML 5 promises, it is still several years from being a viable alternative. Running a comparison of current browsers, only Safari and Chrome even come close to supporting the full set of features, and IE 8 is miserable (

Cascading Style Sheets

It should be a given by now that page layout should be done in CSS and not by HTML tables. I still see sites introduced on campus every day, though, that ignore this rule. All modern browsers support CSS 2 pretty well, even IE-7/8 if you allow for conditional comments and a few hacks. Browser support for CSS 3 isn’t complete, but is growing quickly. Most of the elements in CSS 3 are also what I would call aesthetic enhancements rather than layout elements, so you can easily add them into your site if you want and they will degrade relatively gracefully on browsers that don’t support them.

Browser Version
I’ve previously written about browser support. Not much has changed except for the usage numbers for each browser version. IE 6 is currently down to about 7% of users. We will continue to offer only limited support, making sure that content is visible but making no guarantee that the site looks or behaves the same as with modern browsers. IE 7 is generally supportable with conditional comments and CSS hacks, and since it still makes up 30% of users we do need to offer better support for it.

Use of Flash

The slide show feature is too popular among designers to completely eliminate. That being said, we need to therefore look at the best way of building the feature. Flash is evil. I fought hard to keep it off the current site but lost. (Note, this does not conflict with my assertion that the iPhone/iPad is fundamentally broken as an Internet device because it does not support Flash. As unfortunate as it may be, Flash is simply too pervasive for a platform not to support it.) As mentioned above, HTML 5 is not ready for general purpose sites, so that is not an option. Fortunately jQuery and other tools have blossomed in the last couple of years to the point that they can fill the need. For every Flash slide show application that you can find on the Internet there is a complimentary javascript option. The benefit of this method is that is much more friendly to accessibly enhancement technologies such as screen readers. Yes, and iPhone/iPad owners can see it as well.


Traditional left-column navigation is still the norm, but design is getting more sophisticated and navigation is being better integrated into the site. The one thing I will say – DO NOT try to get fancy and make your navigation out of Flash or any sort of javascript function. You’re just asking for your entire site to break if every viewer doesn’t have whatever technology you built it in. Never assume that anything is 100% pervasive besides plain ol’ HTML.

File Sizes

Hardly anyone accesses the web over dialup modems today, so we don’t have to be as draconian as we used to be on file sizes. Nevertheless, creating a page with 100KB of javascript plus another 50 images plus all your HTML is probably overkill as well. Pick your battles in standing up for doing it right, but know that you can compromise on bigger things than we’ve been able to do in the past.

Site Audience

As always, know your audience and design your site with them in mind. What is important for an incoming freshman and what is important for a current faculty member are often quite far apart. The primary audience for the university website is decidedly external, mainly potential students and parents. We have already started tailoring content on the current site to meet those expectations, but the new site will go much further in that direction.

News and Events

News and events will continue to be a big part of the university front page. We actively encourage the various university offices to submit information. We do, however, only accept it in specific manners. In order to get news stories on the front page, simply provide us with a valid RSS feed. We can then add those into the system and select articles for inclusion. For events, we only add events from the university calendar. Any campus organization is free to set up a departmental calendar in the system and submit events. If you do not have one please contact us at and we’ll get you set up.


We do not, and will not mandate a central template for all of campus. I’m probably butchering the wording, but popular usability expert Jared Spool argues that there is no evidence that using templates does anything besides make your pages look the same. In other words, the concept of conformity is vastly overrated. We instead encourage you to build to the “Aggie Family” of page looks.


Without a doubt, mobile is the wave of the future. Right now we don’t get a lot of traffic to from mobile devices, but it admittedly isn’t very mobile friendly. We have had several people ask about mobile sites, so it is important to include here. On principle, I’m not going to revert back to the days of the browser wars where we sniff for every device and throw a different template. We have therefore made a conscious decision to keep the content of our mobile site separate and distinct from that of We look at what services someone on a mobile device might want, and it is generally different from somebody sitting down at a desktop computer. So what then of the main site? How do we make it friendlier for mobile viewing if that is what they want to see? A 950px wide fixed width page presents problems on a phone. Ideally we could have a separate site backed by a CMS that would let us keep the same content in two different looks. We don’t have such a solution, though, so we need to look at more realistic solutions. For the time being that simply means making sure to produce clean HTML that wraps gracefully and avoiding technologies not accessible through phones. John and I are hoping to present on mobile this summer, I’ll post more details and suggestions here once we get our thoughts together for that.

That’s more than enough for now, but to do justice you could easily write a book on the matter. If you think of anything else you’d like to see addressed add it as a comment here, and I’ll do the same.

Tags: , ,

Monday, May 17th, 2010 Style Guide, 2 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

Hospitality: beyond SEO, beyond usability

For too long, webmasters have thought of search engine optimization as if it were nothing more than a form of advertising, and usability as if it were nothing more than accessibility. SEO became a set of clever techniques to get visitors to your site, and usability became a set of rules that might be reluctantly followed.

Now things are changing. The old SEO techniques aren’t working as well or as long. To get high rankings for many competitive keywords, the most important “technique” seems to be, “Have pages that people want to link to.” As far as usability, it turns out that pages that are hard for the disabled to use are probably hard for everybody else to use. Not only are they not accessible, they’re not very usable.

These problems with websites – people can’t find us, people can’t use us – can easily get masked. Most webmasters reason to themselves, “We have visitors, we must be doing something right.” But it’s difficult to know how many more visitors you would have had – how much longer they would have stayed, and how much more they would have recommended your site to others – if you had done things differently. If your site pleases you and your boss, you may hear no complaints. But your potential visitors are not you or your boss. They haven’t even visited yet. You may not know much about your potential visitors at all.

Both findability and usability have a bad name in some circles. People see web pages where the keywords limit the writers, and where usability rules limit the designers. We need to go beyond that. Content that isn’t interesting or natural, or design that isn’t attractive or even bearable – that’s not usable. That’s not optimized. Not if visitors can’t stand to use it. As Stephen P. Anderson notes, researchers have found that attractive things work better.

Instead of findability or usability, let’s try another word – hospitality. Our visitors are truly our guests. Our websites need to say, “Howdy! Glad you’re here. Can I get you anything? Are you finding everything you need?”

Tags: , ,

Tuesday, November 10th, 2009 Search, Usability 2 Comments

Minor Post, Major Find

Excellent library of usability articles from Jared Spool and others at

Wednesday, November 4th, 2009 Usability No Comments

Budget Usability Testing

Is web usability testing possible for less than $50, in less than 2 hours a week? That’s what Chas Grundy of the University of Notre Dame said in his eduweb conference session. So while John and Erick are at HighEdWeb, I’ll finish up with my own conference notes.

Usability testing can be as simple as sitting 3-5 users down in front of your website, and watching what they do. With screen capture software and/or a webcam, you can even record them.

Chas offered several suggestions and encouragements on web usability testing.

  1. Focus on the big issues. Begin today.
  2. Decide what to learn, how to learn, who from, when to test. Most users are similar. If high school students can’t find your “Contact Us” button, neither can rich elderly potential donors.
  3. Explain to the users that there are no right/wrong answers. In fact, they’re not being tested at all – the web developers are.
  4. Test early, test often. Don’t wait until the site is set in stone.
  5. You can test using paper prototypes and mockups, even before your site is finished.
  6. Test competitors’ websites too, to see if alternatives work better than what you’re doing.
  7. When you test, give users tasks. Don’t leave it open-ended.
  8. Encourage your users talk out loud over the tasks, but don’t offer any direction yourself.
  9. If you ask about something, people will create opinions where they had none before.
  10. What web users say is not always what they do. Ignore speculation.
  11. Fix the obvious, do special testing on the hard parts, then retest.
  12. Design once, increment forever.
  13. Remember: everything we do could be wrong. We don’t know until we’ve tested it.

Chas suggested several usability testing software tools…

…and several websites on usability and usability testing:

  • – The online home of Web usability consultant Steve Krug, author of Don’t Make Me Think.
  • – For usability research, many turn to Dr. Jakob Nielsen’s website. For graphic design beauty, they usually look elsewhere.
  • – A one-stop source from the U.S. Department of Health & Human Services on how to make websites more usable, useful, and accessible.

Tags: , , , , , , , , ,

Tuesday, October 6th, 2009 Usability 1 Comment

Can visitors quickly sniff out your web content?

Web searchers have been compared to hunters and gatherers, trying to find the most likely sources of food without using up their strength. Professor Marcia Bates compared it to berrypicking. In the Information Age, we’re looking for information scent to tell us which websites, which web pages, are most likely to give us the answers we need.

As a berrypicker myself, I can tell you that blackberries and dewberries don’t have much scent until you get very close. And that’s the point: you don’t want to wear yourself out trudging over to a berry patch if it has few berries on it. Especially if you’re on the verge of starvation. You don’t want to waste your time clicking on a search result just to see if it was worth clicking on. Me, I work by sight. From a distance, I can identify which plants are berries, how big they are, and if the light is right, how many berries they have. I have to. They say that berrypicking is leisurely, but whoever said that wasn’t as hungry or as passionate about berries as I can be. True berry connoisseurs need quantity as well as quality.

One evidence that web searchers are like berrypickers is the F-shaped pattern you see in eye-tracking heatmaps for search result pages. That is, studies show that when people do a Google search, they don’t even read the whole sentence. Most noticeably, they scan down the left side of the page, looking for information scent. They read some of the top page titles, which are in bold, and read the first part of the top descriptions, but as they go down the page, they read less and less of each result. They almost ignore the last results.

Why do searchers speed-read through Google? Because with all its technology, Google still can’t read their minds, and still provides more information than they have time to review. Words such as “welcome to our site” have no scent, so they have to keep moving.

Sometimes the stakes in search can be high. Later this week, I’ll share a personal example of how information scent helped me find answers during my wife’s recent health emergency.

The World Wide Web is too big for us. Google has indexed one trillion pages. As of last year. It has indexed more now. Finding the right information scent when you search is a matter of life and death. Because, before you’ve wandered through a trillion irrelevant pages to get answers to your question, you’ll be dead.

Monday, June 22nd, 2009 Search, Usability 1 Comment

Web Style Guide Released

For those of you who have been anxiously and patiently waiting, we are ready to release our version of the Web Style Guide.  We are publishing it as part of the blog site in an effort to make it a dynamic and growing document — something that will be open to your comments and interpretation.

Modeled as a companion piece for the print Brand Guide, this document is more a set of best practices than it is a set of mandated decrees. The idea is to create a common philosophical ground for web design while still allowing plenty of creativity and design control to remain with your offices.

Friday, February 6th, 2009 Style Guide No Comments

Browser Language Settings

Today we had an interesting problem with Facebook where the Texas A&M fan page was showing up in french unless the user was logged in. I started trying to find sites that used the browsers language preferences instead of the page preferences and quickly found out how bad internationalization of pages is coming along. Not even or honor browser preferences. We have the problem here of not having translation staff to help us with content.

But I would figure major government and news sites might put forth the effort to translate and do so with the OS or browser preferences in mind. Several sites have an English and a native language version (ex: Al Jazeera). Some US sites have English as the default and then a Spanish version ( Does your site allow browser preferences to determine language? If so, how do you handle the content translations and what processes do you use to determine which version to serve up?

Thursday, January 22nd, 2009 Miscellaneous, Usability No Comments

Local Validators (HTML, CSS, RSS/Atom) Live!

Drum roll please! The webmasters group is proud to bring you local copies of all three validators! The HTML validator has been up for a while. You can find it by going to

The second validator, which admittedly took us a while to bring up, is used to validate CSS 1 and 2 and is available at

The final validator – a little bonus for being so patient with us on the CSS validator – is the RSS/Atom feed validator available at Try this example (one of our feeds) to see the results.

Sure, you could use the external services available at, but your site will have to be exposed through the firewall. The beautiful thing about our local validators is that they are fast, useful to sites not available through the firewall (test and dev sites), and can be entered into Firefox and Opera as the default validators when using plugins such as the Firefox Web Developer Toolbar.

Tags: , , , , ,