Friday, July 24, 2015

Widgets and Why I Can't Wear an Apple Watch

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

Tracking Code

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.


Thursday, July 2, 2015

Future of Web Editing: Proactive versus Reactive Compliance

I went to my brand new medical specialist the other day, and like with any new client, he asked me what I do for a living. I told him I was a web designer and developer. He remarked that he has a website and someone who works on it, but he knows how busy the developer is, so he thinks he should update the website himself.

This is a response I hear quite often from across the campus. Only a decade ago, everyone with a computer connected to the Internet was getting into the latest web editor they downloaded and sprucing up webpages related to their work and hobbies. And we all called ourselves “Webmasters.”
It was simple enough, right? After all, it is technology, and technology is supposed to be smart enough anybody can build a webpage.

Supposed to be.

But it isn’t.

And that was the shock I received at the first accessibility conference I went to a decade ago. Anyone can build a webpage with the numerous drag and drop options available, however, most are not aware of the accessibility challenges, not to mention content strategy or information architecture. We can do a lot with technology, but technology is only as good as what we put into it. Without the proper knowledge, web maintenance is becoming a far more specialized practice only individuals with a minimum set of technical skills qualify to accomplish.

Our goal as we progress is to make it easier for less technical staff to maintain websites and help technology literate staff keep up with compliance standards at the same time. A new strategy we will be implementing will use a technique commonly used on word processors.

Think back to the days of the typewriter. Yes, they still exist, and their sound is unforgettable to those of us who have used them, but you may recall the typewriter never told you that you misspelled a word.

Yep! You remember reading through your work and cursing under your breath as you had to start all the way over. Well, that is unless you had one of the newer typewriters that let you go back and erase a typo. And it improved through various intervals until we started typing on computers in these technological contraptions called word processors.

Example of a word processor warning a user of a misspelled word.

Then they got really smart! They started to warn us about our misspelled words! Eventually, they were programmed to figure out what we intend to say despite our poor typing skills, and now they autocorrect text for us.

The same kind of proactive warning system has not been done to make web content accessible. For example, web maintainers remember their days writing research papers and using underlines for the titles of books. However, underlines on the web are used primarily for links. People often get confused about what is a link and what is not when they see the underline, imagining they will perhaps hit an online store selling that book only to click on a non-reacting webpage. Web maintainers receive no warning when they underline text for web content telling them they are using the style inappropriately.

This means what I do right now checking our website for accessibility compliance issues is very reactive. I go through webpages manually to check if web maintainers are inappropriately using the underline style for web content. Then I tell them where the problems are, why underlining content that isn’t a link is inaccessible, and ask them to remove the style from their text. I have a very large website to scan and it is very slow process. And that is only one piece in a very long checklist of accessibility compliance issues!

However, with Project Squishy, we will be improving all that in two ways:

1. Appropriate Styles and HTML Tags

Example of Cascade Server's WYSIWYG warning a user of an inappropriate style in use.
Many of the styling errors that web maintainers make currently will have warnings appear around them as they use styles inappropriately, just like a spell check or grammar check. If the maintainer does not correct it in the WYSIWYG editor, the content will still not appear with the styles they had placed on the text when they publish the page to the live website.

This also goes for HTML tags that have been deprecated, such as the old acronym tag (see the full list of HTML 5 tags, plus the alternatives for deprecated tags).

2. Properly Structured Page Content, Alternative Text, and Appropriate Writing for the Web

Preview mode in Cascade shows a warning for the text that was inappropriately styled along with the reason and options for correcting the issue.
Previewing a page inside Cascade will show a warning for many more issues that are inaccessible, including missing or inappropriate alternative text, bolding or italicizing of entire paragraphs, and using headings to increase the font size of entire areas of content that should be paragraphs.

These issues will only appear in the Preview mode inside Cascade Server, along with the reason and options to fix it. When maintainers publish the content without fixing the accessibility issues, the content in violation will not publish.

It will also autocorrect inappropriate spacing and punctuation.

I’m working on more issues as Cascade allows me to resolve them within the system in order to provide maintainers the quickest turnaround on accessibility compliance checking. This proactive approach will help web maintainers receive immediate warnings of inaccessible content issues as well as teach them what to do without me having to review the content and write responses each time.

The Future of Proactive Accessibility Checking

My solution inside Cascade Server is not a full accessibility compliance check, but it is a step in the right direction for all of us. Many things will still need manual checking, and web maintainers will still need training on how to make content more accessible, just like we did when we learned how to write research papers on typewriters.

I do see some potential areas for technology, on its own, to catch some of our mistakes. For example, we cannot insert an image into a webpage and generate automated alternative text for it based on what is seen in the image currently. However, The Wolfram Language Image Identification Project is making some major strides in image identification such that if we were able to implement it into web editors, we would, at minimum, be able to generally describe images based on what their databases believe all those pixels in their specific pattern on the images represent.

The only problem with this is similar to problems with textual autocorrection. Does the alternative text accurately describe the mood or intention of the web maintainer who inserted the image into the page? What about artistic expression? Yes, we will all be laughing at the funky automated identification responses just like we already do with textual autocorrect from our “smart phones.”