I love new technology (new toys!), and I most certainly got excited when Apple was getting ready to announce their Apple Watch (which I still accidentally call an iWatch because all their other mobile devices start with "i"). Their smart watch isn't the first to hit the market, though. Android already had smart watches out for a couple years, but since I moved to an iPhone, I never looked at them as a possibility.
I do not have brand bias. I went to an iPhone because my family are all on iPhones, and they refuse to video chat in any other application than FaceTime. That's not to say we didn't test other video chat apps. They didn't compare to the quality or my family refused to create a new account just to use one app, so those requirements basically forced my decision on the brand I use personally. At work, though, I use everything because I test everything to see how different devices react to our website as well as how each one works to the advantage or detriment of our website's functionality.
It was with great sadness that I decided I could not wear the Apple Watch, but the Apple Watch wasn't the first smart watch I tried before making this decision. I had joined the university's fitness program and tried out the new Fitbit tracking watches we were given, and before that I tried a different fitness watch. I had the same results each time: they cut off my circulation, putting my hand and wrist to sleep. And no, it wasn't the typical "user error" of keeping it too tight.
Downside: I can't appreciate the joys of the Apple Watch without risking putting my hand to sleep.
Alternative: I can still use my iPhone to answer phone calls, check the time, view the map, read my mail, and all the other things that are easier to read on the larger screen anyway.
Not too bad, just not as cool as the new technology, but I can still function with the alternative option.
It's these kinds of decisions that I make in my personal life that I also have to make when web maintainers request to embed some kind of code, typically a widget, onto their web pages. In respect to our website, I have to look at web, compliance, and security standards as well as our Tarleton branding guidelines.
If the code you request to embed on our web pages doesn't pass the tests, then we cannot embed the code onto our webpages, however, where possible, we can still link to an external website that provides the content in its original form.
Just keep in mind when doing research for awesome technology to add to your website, you should include Web Services in the investigation of such products to determine if the safety or privacy of our constituents is compromised or the content is not accessible, as well as all the standards we must follow. Including us helps you ask the vendors the right questions, so we can get you the product you want without the vendor's response going over your head.
Things Coming Down the Pipeline
Please note per our Web site Terms of Service (under Scripting languages and allowed packages) that all code you wish to embed on your website must be approved by Web Services before it can be implemented.
We do have a lot of legacy content on our website that will not be transferring over to the new website due to the programming issues I mentioned in Responsive Design Next Level: Entirely Modular Pages. As we receive new requests for certain types of "widgets" (feeds, modules, or other embedded code), we discourage further or additional use of those "widgets" or encourage other temporary solutions as we look for new solutions.
These are a few that are coming down the pipeline.
Flash "Widgets" (uses Adobe Flash Player, as opposed to apps in an app store)As we move over to responsive pages in Project Squishy, we have to look at how any "widget" can adjust to the screen size of any device. If the content cannot squish into the screen, we are encouraging web maintainers to find alternative solutions as they will not be accessible to users of those smaller devices. Many of our current "widgets" have a forced set of dimensions that would, therefore, not be transferable to the redesigned site.
Adobe Flash products have had consistently negative feedback from users with disabilities. Accessibility advocates discourage its use in place of HTML5 alternatives.
Adobe Flash has had other negative feedback as well, including poor support on mobile devices as well as security risks. Apple mobile devices don't support Flash, period. Firefox is heading that direction. Even social media executives are asking Adobe to finally say goodbye and accept the HTML5 solution.
There is no more general support for Flash, so in the end, we really need to convert everything off as soon as possible for accessibility purposes. You don't want to prepare for the end-of-life date after you cannot view your Flash products on browsers like Internet Explorer or Firefox. Prepare for its expected end-date, and do research on alternatives now! Contact Web Services for assistance in possible solutions.
How do you know it is a Flash widget?If you right-click on the widget in your browser, and it shows a menu option "About Adobe Flash Player [version]", that is a Flash widget.
The following is a short list of examples that will not be transferable, along with our home-grown Flash widgets:
- Prezi presentations: you should only link to these on the Prezi website.
- Photobucket, Flickr, and other photo (and music) slideshows or galleries: we have slideshow solutions in the redesign for very small slideshows, and for larger slideshows we also encourage links directly to the albums or album slideshows.
- Music players: contact Web Services for options
- Online form software: we use an enterprise solution called Wufoo
- Calendar/events solutions: we use an enterprise solution from ActiveDataX, and we can refer you to alternative solutions.
- Clocks and countdowns: we are currently investigating options
- Chat room software: we are currently investigating options
Social Media Widgets
Before we even considered a redesign of our website to be responsive, we were already having trouble with embedded social media widgets, like the social feeds. Originally, we could pull the content (via a feed file) and style it to our own liking, however, these larger social media outlets have been wary of their competition using their platforms to promote their competing products, and they decided they wanted to control the entire look and feel of their platforms to direct their users to their own services. Remember when Instagram stopped showing previews of their photos on Twitter to increase viewership on their own platform? Or how about the Periscope vs. Meerkat showdown?
They now insist we use their proprietary code, look and feel. Sure there are a few customizations, but we are at their mercy at all times.
We've tried before to fix issues. There was a Facebook feed widget issue that popped up a few times throughout one year where the size had gone outside our template's layout. I'd muck with our webpage's styles to try to fit it back in the boundaries and display at the right text size, but as soon as Facebook fixed the widget, my temporary fix broke the widget again. I'd have to go to every single webpage that had the Facebook widget, and fix each and every one. Twice. Each time.
If your page is not working correctly because of the social media feed, our hands are tied during that time the vendor is working on the fix while your page looks broken and unprofessional.
Given the instability of their code, we have discouraged new requests for embedded social media widgets, and will not be moving them to the redesigned site unless we can find a proper alternative. Given the lack of support for customization of widgets from these social media outlets, we are not hopeful for solutions at this time but nevertheless are on the lookout. We still allow links to your social media pages per our social media guidelines, and that alternative has been available since before we learned of their codes' instability.
The following is a short list of examples of social media widgets that will not be transferable until we find proper alternatives:
- Social media feed, follow, like, etc. widgets
- Social media mass share widgets (e.g., AddThis, ShareThis)
- Comment/discussion widgets
- Ratings widgets
Web Services uses Google Analytics tracking code to help you determine what is working on your websites, what your constituents are interested in, and what needs improvement or removal due to lack of interest from your target audiences. We consult with web maintainers based on university, department, and program goals and our constituents' needs when accessing our website content. However, when additional tracking code combines with our code, our analytical data gets skewed (e.g., duplication or removal of important information), so we cannot provide proper consultation services to you.
Typically, tracking code (like Google Analytics) is hidden from sight when our constituents view a website. This is good because we don't necessarily want people to see those page view numbers which only tell a partial story about the page's usage anyway. Some might interpret them as good while others might think they are bad. But what you don't know is that hackers can see these embedded code snippets and exploit their security flaws to hack our website. One of the many approaches they use is "injection". In this scenario, they don't have access to Cascade Server or the web server itself to make changes to our webpages, but they can view the code of our website, find a backdoor in any weak programming, and inject malicious code onto our webpages and server. Flash widgets are what we typically hear about having these flaws, but any code has the potential to create security leaks.
If you have any questions about "widgets" or code you want to embed on your website, please let Web Services know what you are researching, and we can help you determine your best options.