Does your building have digital signage yet? This might be a flat panel on the wall welcoming guests… showing things like office locations, event schedules, departmental information, or any number of such things. If you have digital signage but are on an old system, or if you haven’t made the move yet at all, there is a project underway on campus that you might be interested in. Student Affairs, along with over a dozen other units across campus, has contracted with Four Winds Interactive to bring their display product to campus. View their gallery for a good idea of what can be done, from museum quality, interactive touch-screen koisks to static displays that rotate on a loop.
By joining together in a larger campus license we are able to employ enterprise leading services while significantly reducing the cost of doing it on our own. Specific information on this initiative, including who to contact if you are interested in joining, can be found on the project page maintained by Student Affairs.
Since everybody is getting new smartphones except me, I need to add high-resolution images to the sites I design – but until now, I couldn’t see what they looked like on a high-resolution device without borrow somebody’s phone. We use media queries to serve larger images to retina devices, and zooming my browser won’t trigger these media queries.
But there is a way to simulate a retina display on a Firefox browser.
- Go to “about:config”
- Find “layout.css.devPixelsPerPx
- Change it to your desired ratio (1 for normal, 2 for retina, etc.)
When I run these tests, the pages get so big it’s hard to use Firefox for anything else, but I can quickly tell which images will work on retina (the crisp ones) and which images need to be swapped out (the blurry ones).
I learned another retina solution from Monty Dickerson: use larger images that have half the quality (Photoshop 50) but four times the pixels (100 x 100 instead of 50 x 50). It’s counter-intuitive, but they aren’t much heavier than traditionally-sized images, yet look much better, even on normal monitors.
Over the past couple of months I have been asked by several web developers new to campus about whether we have some sort of group for web professionals to meet and discuss projects, problems, and other matters. It is becoming increasingly apparent that there is both a need and a desire for this sort of thing. Those of you who have been here for a while might remember our earlier effort to revive uWeb. I think it is time that we take another stab at it.
I would therefore like to invite you all to the first meeting of the reconstituted uWeb on Friday December 6 at 3:00 in room 2406 of the MSC. We will try to meet roughly monthly after that and present on topics (both ours and yours) that affect us all.
Killing two birds with one stone, we will be talking about the SiteImprove contract that we recently signed. The vendor will be presenting the service through a live webinar and will be available to answer your questions. I know several of you have talked to me already about joining in but have to convince others who are in charge of the budget. I hope that being able to look at real sites on campus will give you the leverage that you need to show how useful the service will be. If any of you would like to volunteer your site to be one of the demos please send me the url.
We made a minor change to one of our sites last week that had a dramatic effect on me, and really brought home how powerful the social media movement is…and thereby how important it is for our marketing efforts. At first glace the change looked innocuous enough … we were asked to move the “share” icons on our news stories from the bottom of the page to the top so that more people would be tempted to click the button.
The news site is built in WordPress, so of course these icons were part of a WordPress plugin. An old one as it turned out, that didn’t make it easy to change the location of where it gets displayed on the page. The icons were a bit small too, so we decided it would be easier to simple drop it and go grab a different plugin instead. The difference was night and day.
The old plugin simply displayed the icons for people to click. The new one, (AddThis), went a whole lot further. I had used AddThis several years ago, but its capabilities have grown immensely since them. Now it lets you set up an account so that you can log in and view the analytics of how your content is being shared. Not only can you track the actual clicks and shares on your site, but it shows the added reach that your content gets from being added to social media platforms.
The “viral lift” is the extra clicks that your story gets from those social platforms. One of our stories from this week, for example, has been shared 114 times. Those 114 shares have led to an additional 4,454 visits to that story, which was 75% of the total page views.
Looking across the board, links from social media dwarf all of the other avenues by which people find content on the news site. For most sites, Google is far and away the largest referrer. For the entire news site it is Facebook instead, by a wide margin.
I will be the first to admit that I would have never imagined this kind of shift had we not been asked to make that one seemingly insignificant change. Now, I really have to step back and completely re-evaluate our strategy for integrating social media into everything that we are doing. If sharing can boost visibility on these news stories, we have to start looking at how much it can add everywhere else.
Good news, the SiteImprove service is now ready for us to start using!
The long term plan will be to have it administered by the system, and have the system bill users directly. A web-based order form will eventually be created, but until In the meantime Mark Stone and the SiteImprove vendor rep have asked me to start coordinating with users on campus who would like to subscribe to the service to get your sites into the system.
The rate that I have been given is $0.54 per page per year.
We are encouraging anyone who wants to subscribe to the service to go ahead and send me your information. I will pass it along to SiteImprove and they will add your sites and users to the system so that you can start using it.
Please send me (firstname.lastname@example.org):
- Your organization’s name (Your college, department, division, office, or whatever)
- Name and email address of staff who will be users on the system
- The URL of all sites that you want monitored
Note that you can also exclude parts of sites from being monitored, so include any directories within each site that you want to be excluded
- A maximum page allotment that you want to pay for (for example, if there are 11,000 pages in your combined URLs but you only have funds to pay for 10,000 we can set a limit on the number of pages crawled.)
The TAMU System has signed a contract with SiteImprove for their website monitoring service. This will allow access to their Quality Assurance and Accessibility modules. I have been able to have a few of my own sites enrolled during the negotiation process and can testify to the value of the service.
The System offices are still in the process of getting training for the administrators and getting billing information set up. Once they get that information I will pass it along and let you know how to get your own pages monitored.
(This article also posted on GoMobile!)
Over the next year our group plans to rebuild both the university main web site and the mobile web site. One of the discussions that came up was whether to detect the user’s device on both sites and route mobile devices hitting www.tamu.edu to the mobile site and desktop users hitting m.tamu.edu to the full site. Based on the behavior that I have seen on many university sites this is a discussion that takes place throughout higher ed. Many get it wrong. The answer, of course, is an emphatic NO!
For the philosophic reasoning, let me first go back to what I consider the central truism of our job. Visitors come to our sites for a reason, which is to find a particular bit of information. People no longer “browse” sites, following links from one to another to see what is there, like we did back in the early days of the internet. They want to find out something, and it is our job to help them find it quickly and easily. Any interruption or delay in this process represents a bad user experience, and we know from dozens of studies that dissatisfied users will leave and not come back.
Redirects are a perfect example of such an interruption. We as developers have been trapped by the proverbial box. We see that users come to the site from a particular device so we cleverly think that we should “make it easier for them” by redirecting them to where they “really” wanted to go. But is our assumption of where they want to go valid? Probably not. Most university mobile sites are not simply the mobile version of the full site. They are instead designed to feature content that is useful mainly to people on campus who are themselves on-the-go. Two years ago that would have described what most people with a mobile device would be looking for. Today, though, the majority are causal users who expect to be able to see all of the content of the sites they are visiting…which is to say the responsive view of the full site. Redirecting mobile devices from the full site to the mobile site, then, is today more likely to give them the wrong information than helping them find what they were looking for.
Our team discussion went further than this, with one side advocating redirecting devices to the mobile site even if the full site is responsive. The problem with this method is that it fails to see the paradigm shift that has taken place in the last couple of years. It argues that if you use a mobile device you should get the mobile site (i.e. the site designed for on-the-go users) and that if you really wanted the full site you can link back to it. That is a dangerous assumption because it not only fails to take into account the intent of the user but actually mis-identifies their intent and points them to the wrong location.
From a pragmatic standpoint we should avoid redirects because their time is simply over. Responsive design has answered the question of how content should best be served to a mobile device. Two or three years ago it might have been understandable to redirect a mobile device to a mobile site since the full site probably was not mobile friendly. Today there is no excuse for the full version not to be responsive. That, then, should be what people on mobile devices are allowed to see.
What about the case of redirecting desktop users? When many mobile sites today detect a desktop user they redirect them to a special landing page telling about how the site was built, what features are included, and (maybe) a link to actually view the site content. Why? When we visit a site we want to read its contents, not learn about the framework that created it. We don’t build special pages on our full sites telling how we built it, and mobile sites shouldn’t be any different. If somebody visits a mobile website from a desktop browser, send them straight to the site content.
A quick glance at our mobile site’s analytics shows that many on-campus staff regularly use the mobile site in their day-to-day jobs from their office desktops. They have very similar needs to on-the-go users and prefer going to the mobile web site to get all of that information in one place rather than going to a dozen different full sites to get it all. In this way we get them the information they were looking for quickly and easily. If we had instigated a redirect on the site they probably would have turned away on their first visit, never came back, and therefore never gained the benefit of using the mobile site.
In summation… leave the user’s choice of where they are going up to them. When we as developers start assuming that we know better than the user what they themselves are looking for we are generally going to be wrong, and in turn create a bad user experience and a frustrated user.
Our normal workflow is often interrupted with special projects that we are assigned. For the last several weeks we have been working on the “Fifty Years of Inclusion” website, which showcases many of the important steps toward diversity that the university has taken in the last fifty years. This project involved people from all over campus, so a special thank you to anyone who participated.
We will now be turning our attention back to making progress on the web branding guidelines, as well as beginning an overhaul of the TAMUmobile apps and web. You can expect to be hearing more about both soon.
We will have several of our team at An Event Apart in Austin next month. Is anyone else planning to attend? If so we should definitely meet up and compare notes.
This will be the first time in several years that no one from our office will be the attending HighEdWeb conference. I always enjoyed attending this one, but travel options to Buffalo were less then ideal. It would also be a 3-day turnaround in getting back from An Event Apart and leaving for this HighEdWeb, which wouldn’t give much catch-up time back in the office. Maybe next year. If anybody does go, give us a call when you get back, I would love to chat about what went on.
We made the switch over to the Google Custom Search Engine (CSE) on Monday and have not had any issues. There does seem to be a slight delay between loading the page framework and when the search returns populate the page, but that was to be expected and is not terribly distracting. All of the features that we moved over from the GSA are working nicely, and we have started investigating some of the new features that the CSE gives us.
If anybody on campus who made the transition is having problems, give us a call and we will do what we can to help get the transition smoothed out.