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.
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 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.
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.
I sent out a note earlier today to the calendar-announce email list regarding calendar widgets in the upcoming version of the calendar. I’m repeating that here for those of you not on that list. (If you aren’t on the list and have a departmental/organizational calendar on calendar.tamu.edu I highly encourage you to go to the listserv site and sign up to insure that you receive timely announcements about service updates, outages, etc.)
We are about a week away from launching the new version of the calendar. I am trying to make sure that those of you who pull event information through the calendar widgets have as seamless of a transition as possible. However – the widgets do pull directly from the code that creates the website, and some of that has changed.
I have created a sample page that drops in the default templates. I have noticed that it is possible for local site styles to conflict with and overwrite the styles for the calendar. If that is the case for you, please get in touch with us and we can help you set up a custom CSS file to fix your issues.
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… 🙂
It isn’t often that I radically change my opinion about anything web related. I’ve been doing this for so long that I’ve always been able to adapt and adopt new concepts incrementally. That mindset was completely shattered this week when I finally took a real in-depth look at the cutting edge of CSS3.
I have been watching its development for a while, but never paid it serious attention because without standardized browser support I knew it wouldn’t be anything we could implement. Maintaining the main university site means making it accessible to the masses, which in turn means coding to a quite low common denominator. The nature of the sites we work on precludes us from using all the bells and whistles that can be put onto a site catering to a more sophisticated user base. Most of my thoughts of CSS3 were therefore that it was basically nice, but mostly aesthetic, improvements that could be incorporated into sites — visible to the more advanced browsers and gracefully degrading on browsers that don’t support the technology. This philosophy is nicely summed up by the webmasters from Wayne State University.
What I’ve seen in the last few days, though, convinces me that I was vastly underestimating the importance of the HTML5/CSS3 combination. While it admittedly isn’t here yet, I’m now firmly convinced that it will make modern web development (and developers if we don’t learn and adapt) obsolete. The introduction of CSS2 was problematic to a lot of developers because it forced a break from our traditional linear chain of thinking and implementation. CSS3 is going to go way past that. Even imagining what can be done with the technology is going to require a new way of thinking, and to be among the leaders that thinking will have to be way outside the box.
As a quick demonstration, take a look at some of the online demos at the WebDesignerWall blog. (You’ll need Safari or Chrome to get the full effects.) These are admittedly isolated demos that serve as proofs of concept rather than elements for a live website, but they show that base HTML/CSS can take the place of a lot of the jquery that is seen as leading edge today. The line between application design and web design is going to get even more blurred as we are able to do more and more with basic styling. The gap between designers and developers is also going to narrow, as both are going to have to have an increased understanding of the other’s area of expertise in order to do their own job.
Maybe I’m late to the party in this realization, but when I look at the state of so much web development today that barely scratches the surface of CSS2, I can’t help but think that a lot of developers are going to be in for a rude awakening. It might take a few more years, but we are going to experience a complete paradigm shift, and we need to start getting ready for it now.
We’re pleased to announce a new tool to help you customize your departmental calendar on your own website: an editable cascading style sheet so you can match the colors to your site’s look and feel, plus instructions on how to use it.
We think this new style sheet will let you seamlessly integrate your calendar into your website’s design. As always, contact us if you have any questions about making the most of the university calendar system, or if your group would like a calendar of its own.
Also, the Full Calendar widget has been much improved. Thanks to Donald St. Martin, the widget now automatically detects the current month and year, which makes it much easier to keep your site up to date.
Instructions on how to use all four widgets can be found in our calendar documentation, as well as 15 helpful hints for calendar administrators, including several new solutions to common problems (many of which we already announced on our email list.)
We have put the finishing touches on the validators we announced in late January. There are now several ways to get to the validators depending on how you best remember them. The W3C validators are not all at one URL, so we’ve taken both approaches. You can access them from the subdomains the W3C uses (jigsaw, feedvalidator, etc) or you can use the validator.tamu.edu base domain with paths.
If there are any other helpful open source validators you would like to see inside the firewall please contact us and we will see about getting them online here. These validators are part of our commitment to helping the campus community produce the highest quality web work possible.
W3C HTML Validator
W3C CSS Validator
W3C Feed Validator (RSS and ATOM)