Feed aggregator

Implementing IBM FlashSystem 900 Model AE3

IBM Redbooks Site - Thu, 03/22/2018 - 09:30
Redbook, published: Thu, 22 Mar 2018

Today’s global organizations depend on being able to unlock business insights from massive volumes of data.

Categories: Technology

IBM HyperSwap for IBM FlashSystem A9000 and A9000R

IBM Redbooks Site - Wed, 03/21/2018 - 09:30
Redpaper, published: Wed, 21 Mar 2018

IBM® HyperSwap® is the high availability (HA) solution that provides continuous data availability in case of hardware failure, power failure, connectivity failure, or disasters.

Categories: Technology

IBM TS4500 R4 Tape Library Guide

IBM Redbooks Site - Wed, 03/21/2018 - 09:30
Redbook, published: Wed, 21 Mar 2018

The IBM® TS4500 (TS4500) tape library is a next-generation tape solution that offers higher storage density and integrated management than previous solutions.

Categories: Technology

Exploring IBM Db2 for z/OS Continuous Delivery

IBM Redbooks Site - Wed, 03/21/2018 - 09:30
Redpaper, published: Wed, 21 Mar 2018

This IBM® Redpaper™ publication provides key information about continuous delivery in IBM Db2® 12 for z/OS®.

Categories: Technology

Review: PowerPort+ 5 Ports USB-C -- fast-charge an iPad Pro, iPhone X or iPhone 8, plus charge four other devices

iPhone J.D. - Wed, 03/21/2018 - 00:37

Back in 2015, I reviewed the Anker PowerPort 6, a great device that lets you plug into a single wall outlet and charge six USB devices at once.  Since then, that device has been an essential part of my travel gear.  It is nice when you only have to locate one available outlet in a hotel room, conference area, airport, and be able to charge multiple devices.  Often, that Anker charger was the only charger that I needed on a trip.  That changed when I started to use an iPad Pro in early 2016 because a traditional USB-to-Lightning connection takes a long time to charge the powerful iPad Pro.  Ever since March 2016, I have mostly charged my iPad Pro (or iPad Pro 2) using Apple’s 29W USB-C Power Adapter and Apple's USB-C to Lightning Cable (my review), which charge much more quickly.  So when I traveled, that meant carrying two chargers.

To try to get back to carrying one charging unit during travel, a few weeks ago I purchased from Amazon Anker's PowerPort+ 5 Ports USB-C, a single unit which features both a single USB-C port for fast-charging, plus four other USB ports.  I've used this device on two out-of-town trips, and it has worked very well.

If you are familiar with the Anker PowerPort 6, the PowerPort+ 5 Ports USB-C looks very similar.  If you put them side-to-side you can see that the PowerPort+ 5 is just slightly larger (height of 1.1" versus 1", width of 4.06" versus 4.9", depth of 3.07" versus 2.8") and just slightly heavier (7.5 oz. versus 6.7 oz) but in normal use I never noticed those slight differences.

One difference between the two is that the PowerPort 6 has a blue light that goes on when the unit is plugged in.  It's nice to have an indication that there is a charge, but it is sort of annoying to have that blue light in a room at night.  The PowerPort+ 5 doesn't have any light, and I think I prefer that.

That main difference is that while the older PowerPort 6 has six USB ports, the newer device has only five ports. But one of those ports is special — it is USB-C and supports the same 29W that the Apple USB-C charger supports. 

When you need to charge an iPad Pro, the faster USB-C is a noticeable difference.  As I noted in my review of Apple's power adapter, you can charge an iPad Pro twice as fast.

When you need to charge an iPhone X or an iPhone 8, those devices can also get a fast-charge using USB-C.  However, the difference isn't as big as it is on an iPad Pro.  In this post from Juli Clover of MacRumors, she shows that using USB-C you can get an extra 7% of charge in 15 minutes, an extra 10% of charge in 30 minutes, and an extra 12% of charge in 45 minutes.  If you only have 30 minutes to charge your iPhone X in a hotel room, does it matter to you whether you will end up with a 49% charge versus a 39% charge — keeping in mind that those number are just rough estimates anyway?  My feeling is that I want a USB-C port to get a substantially faster charge on my iPad Pro, and if that also helps me get a somewhat faster charge on an iPhone X, well why not.  There have been times late at night when an extra 10% in battery life makes all the difference.

(I don't travel with a Mac laptop, but if you use one of the newer ones that supports USB-C charging, that is an additional reason that the PowerPort+ 5 Ports USB-C will be very helpful for you.)

The disadvantage versus the PowerPort 6 is that you only have a total of five ports, one fewer port.  For me, this trade-off is worth it because it is rare that I need to use all six ports at once.  For example, at night I will often charge an iPad, iPhone, Apple Watch, and an external battery.  Having said that, there are times when six ports are useful (such as when I'm traveling with my family), and if an extra port is more important to you than having a single fast port, then the PowerPort 6 might be a better product for you.

Although I use this device almost exclusively as a travel companion, I know lots of attorneys who use an Anker PowerPort in a permanent location in an office or home.  That's what my wife does — she keeps a PowerPort on a shelf and uses it every night to charge her iPad, iPhone, Apple Watch, and sometimes another device.

I've enjoyed using the Anker PowerPort+ 5 Ports USB-C for the last few weeks.  It lets me charge lots of devices at once, I have the advantage of fast-charge technology, plus I don't have to carry around the big and heavy Apple power adapter in addition to an Anker PowerPort device.  It's not often that you can say that five is better than six, but if your charging needs are similar to mine, then you will find the Anker PowerPort+ 5 Ports USB-C to be a very useful device and an upgrade over the older PowerPort 6.  And if you are considering purchasing Apple's 29W USB‑C Power Adapter, this Anker product costs the same $50 but gives you four additional ports.

Click here to get the Anker PowerPort+ 5 Ports USB-C from Amazon ($49.99).

Categories: iPhone Web Sites

Implementing the IBM Storwize V5000 Gen2 (including the Storwize V5010, V5020, and V5030) with IBM Spectrum Virtualize V8.1

IBM Redbooks Site - Tue, 03/20/2018 - 09:30
Redbook, published: Tue, 20 Mar 2018

Organizations of all sizes face the challenge of managing massive volumes of increasingly valuable data.

Categories: Technology

Designing for Research

A list Apart development site - Tue, 03/20/2018 - 09:09

If you’ve spent enough time developing for the web, this piece of feedback has landed in your inbox since time immemorial:

“This photo looks blurry. Can we replace it with a better version?”

Every time this feedback reaches me, I’m inclined to question it: “What about the photo looks bad to you, and can you tell me why?

That’s a somewhat unfair question to counter with. The complaint is rooted in a subjective perception of image quality, which in turn is influenced by many factors. Some are technical, such as the export quality of the image or the compression method (often lossy, as is the case with JPEG-encoded photos). Others are more intuitive or perceptual, such as content of the image and how compression artifacts mingle within. Perhaps even performance plays a role we’re not entirely aware of.

Fielding this kind of feedback for many years eventually lead me to design and develop an image quality survey, which was my first go at building a research project on the web. I started with twenty-five photos shot by a professional photographer. With them, I generated a large pool of images at various quality levels and sizes. Images were served randomly from this pool to users who were asked to rate what they thought about their quality.

Results from the first round were interesting, but not entirely clear: users seemed to have a tendency to overestimate the actual quality of images, and poor performance appeared to have a negative impact on perceptions of image quality, but this couldn’t be stated conclusively. A number of UX and technical issues made it necessary to implement important improvements and conduct a second round of research. In lieu of spinning my wheels trying to extract conclusions from the first round results, I decided it would be best to improve the survey as much as possible, and conduct another round of research to get better data. This article chronicles how I first built the survey, and then how I subsequently listened to user feedback to improve it.

Defining the research

Of the subjects within web performance, image optimization is especially vast. There’s a wide array of formats, encodings, and optimization tools, all of which are designed to make images small enough for web use while maintaining reasonable visual quality. Striking the balance between speed and quality is really what image optimization is all about.

This balance between performance and visual quality prompted me to consider how people perceive image quality. Lossy image quality, in particular. Eventually, this train of thought lead to a series of questions spurring the design and development of an image quality perception survey. The idea of the survey is that users are providing subjective assessments on quality. This is done by asking participants to rate images without an objective reference for what’s “perfect.” This is, after all, how people view images in situ.

A word on surveys

Any time we want to quantify user behavior, it’s inevitable that a survey is at least considered, if not ultimately chosen to gather data from a group of people. After all, surveys are perfect when your goal is to get something measurable. However, the survey is a seductively dangerous tool, as Erika Hall cautions. They’re easy to make and conduct, and are routinely abused in their dissemination. They’re not great tools for assessing past behavior. They’re just as bad (if not worse) at predicting future behavior. For example, the 1–10 scale often employed by customer satisfaction surveys don’t really say much of anything about how satisfied customers actually are or how likely they’ll be to buy a product in the future.

The unfortunate reality, however, is that in lieu of my lording over hundreds of participants in person, the survey is the only truly practical tool I have to measure how people perceive image quality as well as if (and potentially how) performance metrics correlate to those perceptions. When I designed the survey, I kept with the following guidelines:

  • Don’t ask participants about anything other than what their perceptions are in the moment. By the time a participant has moved on, their recollection of what they just did rapidly diminishes as time elapses.
  • Don’t assume participants know everything you do. Guide them with relevant copy that succinctly describes what you expect of them.
  • Don’t ask participants to provide assessments with coarse inputs. Use an input type that permits them to finely assess image quality on a scale congruent with the lossy image quality encoding range.

All we can do going forward is acknowledge we’re interpreting the data we gather under the assumption that participants are being truthful and understand the task given to them. Even if the perception metrics are discarded from the data, there are still some objective performance metrics gathered that could tell a compelling story. From here, it’s a matter of defining the questions that will drive the research.

Asking the right questions

In research, you’re seeking answers to questions. In the case of this particular effort, I wanted answers to these questions:

  • How accurate are people’s perceptions of lossy image quality in relation to actual quality?
  • Do people perceive the quality of JPEG images differently than WebP images?
  • Does performance play a role in all of this?

These are important questions. To me, however, answering the last question was the primary goal. But the road to answers was (and continues to be) a complex journey of design and development choices. Let’s start out by covering some of the tech used to gather information from survey participants.

Sniffing out device and browser characteristics

When measuring how people perceive image quality, devices must be considered. After all, any given device’s screen will be more or less capable than others. Thankfully, HTML features such as srcset and picture are highly appropriate for delivering the best image for any given screen. This is vital because one’s perception of image quality can be adversely affected if an image is ill-fit for a device’s screen. Conversely, performance can be negatively impacted if an exceedingly high-quality (and therefore behemoth) image is sent to a device with a small screen. When sniffing out potential relationships between performance and perceived quality, these are factors that deserve consideration.

With regard to browser characteristics and conditions, JavaScript gives us plenty of tools for identifying important aspects of a user’s device. For instance, the currentSrc property reveals which image is being shown from an array of responsive images. In the absence of currentSrc, I can somewhat safely assume support for srcset or picture is lacking, and fall back to the img tag’s src value:

const surveyImage = document.querySelector(".survey-image"); let loadedImage = surveyImage.currentSrc || surveyImage.src;

Where screen capability is concerned, devicePixelRatio tells us the pixel density of a given device’s screen. In the absence of devicePixelRatio, you may safely assume a fallback value of 1:

let dpr = window.devicePixelRatio || 1;

devicePixelRatio enjoys excellent browser support. Those few browsers that don’t support it (i.e., IE 10 and under) are highly unlikely to be used on high density displays.

The stalwart getBoundingClientRect method retrieves the rendered width of an img element, while the HTMLImageElement interface’s complete property determines whether an image has finished loaded. The latter of these two is important, because it may be preferable to discard individual results in situations where images haven’t loaded.

In cases where JavaScript isn’t available, we can’t collect any of this data. When we collect ratings from users who have JavaScript turned off (or are otherwise unable to run JavaScript), I have to accept there will be gaps in the data. The basic information we’re still able to collect does provide some value.

Sniffing for WebP support

As you’ll recall, one of the initial questions asked was how users perceived the quality of WebP images. The HTTP Accept request header advertises WebP support in browsers like Chrome. In such cases, the Accept header might look something like this:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

As you can see, the WebP content type of image/webp is one of the advertised content types in the header content. In server-side code, you can check Accept for the image/webp substring. Here’s how that might look in Express back-end code:

const WebP = req.get("Accept").indexOf("image/webp") !== -1 ? true : false;

In this example, I’m recording the browser’s WebP support status to a JavaScript constant I can use later to modify image delivery. I could use the picture element with multiple sources and let the browser figure out which one to use based on the source element’s type attribute value, but this approach has clear advantages. First, it’s less markup. Second, the survey shouldn’t always choose a WebP source simply because the browser is capable of using it. For any given survey specimen, the app should randomly decide between a WebP or JPEG image. Not all participants using Chrome should rate only WebP images, but rather a random smattering of both formats.

Recording performance API data

You’ll recall that one of the earlier questions I set out to answer was if performance impacts the perception of image quality. At this stage of the web platform’s development, there are several APIs that aid in the search for an answer:

  • Navigation Timing API (Level 2): This API tracks performance metrics for page loads. More than that, it gives insight into specific page loading phases, such as redirect, request and response time, DOM processing, and more.
  • Navigation Timing API (Level 1): Similar to Level 2 but with key differences. The timings exposed by Level 1 of the API lack the accuracy as those in Level 2. Furthermore, Level 1 metrics are expressed in Unix time. In the survey, data is only collected from Level 1 of the API if Level 2 is unsupported. It’s far from ideal (and also technically obsolete), but it does help fill in small gaps.
  • Resource Timing API: Similar to Navigation Timing, but Resource Timing gathers metrics on various loading phases of page resources rather than the page itself. Of the all the APIs used in the survey, Resource Timing is used most, as it helps gather metrics on the loading of the image specimen the user rates.
  • Server Timing: In select browsers, this API is brought into the Navigation Timing Level 2 interface when a page request replies with a Server-Timing response header. This header is open-ended and can be populated with timings related to back-end processing phases. This was added to round two of the survey to quantify back-end processing time in general.
  • Paint Timing API: Currently only in Chrome, this API reports two paint metrics: first paint and first contentful paint. Because a significant slice of users on the web use Chrome, we may be able to observe relationships between perceived image quality and paint metrics.

Using these APIs, we can record performance metrics for most participants. Here’s a simplified example of how the survey uses the Resource Timing API to gather performance metrics for the loaded image specimen:

// Get information about the loaded image const surveyImageElement = document.querySelector(".survey-image"); const fullImageUrl = surveyImageElement.currentSrc || surveyImageElement.src; const imageUrlParts = fullImageUrl.split("/"); const imageFilename = imageUrlParts[imageUrlParts.length - 1]; // Check for performance API methods if ("performance" in window && "getEntriesByType" in performance) { // Get entries from the Resource Timing API let resources = performance.getEntriesByType("resource"); // Ensure resources were returned if (typeof resources === "object" && resources.length > 0) { resources.forEach((resource) => { // Check if the resource is for the loaded image if (resource.name.indexOf(imageFilename) !== -1) { // Access resource images for the image here } }); } }

If the Resource Timing API is available, and the getEntriesByType method returns results, an object with timings is returned, looking something like this:

{ connectEnd: 1156.5999999947962, connectStart: 1156.5999999947962, decodedBodySize: 11110, domainLookupEnd: 1156.5999999947962, domainLookupStart: 1156.5999999947962, duration: 638.1000000037602, encodedBodySize: 11110, entryType: "resource", fetchStart: 1156.5999999947962, initiatorType: "img", name: "https://imagesurvey.site/img-round-2/1-1024w-c2700e1f2c4f5e48f2f57d665b1323ae20806f62f39c1448490a76b1a662ce4a.webp", nextHopProtocol: "h2", redirectEnd: 0, redirectStart: 0, requestStart: 1171.6000000014901, responseEnd: 1794.6999999985565, responseStart: 1737.0999999984633, secureConnectionStart: 0, startTime: 1156.5999999947962, transferSize: 11227, workerStart: 0 }

I grab these metrics as participants rate images, and store them in a database. Down the road when I want to write queries and analyze the data I have, I can refer to the Processing Model for the Resource and Navigation Timing APIs. With SQL and data at my fingertips, I can measure the distinct phases outlined by the model and see if correlations exist.

Having discussed the technical underpinnings of how data can be collected from survey participants, let’s shift the focus to the survey’s design and user flows.

Designing the survey

Though surveys tend to have straightforward designs and user flows relative to other sites, we must remain cognizant of the user’s path and the impediments a user could face.

The entry point

When participants arrive at the home page, we want to be direct in our communication with them. The home page intro copy greets participants, gives them a succinct explanation of what to expect, and presents two navigation choices:

From here, participants either start the survey or read a privacy policy. If the user decides to take the survey, they’ll reach a page politely asking them what their professional occupation is and requesting them to disclose any eyesight conditions. The fields for these questions can be left blank, as some may not be comfortable disclosing this kind of information. Beyond this point, the survey begins in earnest.

The survey primer

Before the user begins rating images, they’re redirected to a primer page. This page describes what’s expected of participants, and explains how to rate images. While the survey is promoted on design and development outlets where readers regularly work with imagery on the web, a primer is still useful in getting everyone on the same page. The first paragraph of the page stresses that users are rating image quality, not image content. This is important. Absent any context, participants may indeed rate images for their content, which is not what we’re asking for. After this clarification, the concept of lossy image quality is demonstrated with the following diagram:

Lastly, the function of the rating input is explained. This could likely be inferred by most, but the explanatory copy helps remove any remaining ambiguity. Assuming your user knows everything you do is not necessarily wise. What seems obvious to one is not always so to another.

The image specimen page

This page is the main event and is where participants assess the quality of images shown to them. It contains two areas of focus: the image specimen and the input used to rate the image’s quality.

Let’s talk a bit out of order and discuss the input first. I mulled over a few options when it came to which input type to use. I considered a select input with coarsely predefined choices, an input with a type of number, and other choices. What seemed to make the most sense to me, however, was a slider input with a type of range.

A slider input is more intuitive than a text input, or a select element populated with various choices. Because we’re asking for a subjective assessment about something with such a large range of interpretation, a slider allows participants more granularity in their assessments and lends further accuracy to the data collected.

Now let’s talk about the image specimen and how it’s selected by the back-end code. I decided early on in the survey’s development that I wanted images that weren’t prominent in existing stock photo collections. I also wanted uncompressed sources so I wouldn’t be presenting participants with recompressed image specimens. To achieve this, I procured images from a local photographer. The twenty-five images I settled on were minimally processed raw images from the photographer’s camera. The result was a cohesive set of images that felt visually related to each other.

To properly gauge perception across the entire spectrum of quality settings, I needed to generate each image from the aforementioned sources at ninety-six different quality settings ranging from 5 to 100. To account for the varying widths and pixel densities of screens in the wild, each image also needed to be generated at four different widths for each quality setting: 1536, 1280, 1024, and 768 pixels, to be exact. Just the job srcset was made for!

To top it all off, images also needed to be encoded in both JPEG and WebP formats. As a result, the survey draws randomly from 768 images per specimen across the entire quality range, while also delivering the best image for the participant’s screen. This means that across the twenty-five image specimens participants evaluate, the survey draws from a pool of 19,200 images total.

With the conception and design of the survey covered, let’s segue into how the survey was improved by implementing user feedback into the second round.

Listening to feedback

When I launched round one of the survey, feedback came flooding in from designers, developers, accessibility advocates, and even researchers. While my intentions were good, I inevitably missed some important aspects, which made it necessary to conduct a second round. Iteration and refinement are critical to improving the usefulness of a design, and this survey was no exception. When we improve designs with user feedback, we take a project from average to something more memorable. Getting to that point means taking feedback in stride and addressing distinct, actionable items. In the case of the survey, incorporating feedback not only yielded a better user experience, it improved the integrity of the data collected.

Building a better slider input

Though the first round of the survey was serviceable, I ran into issues with the slider input. In round one of the survey, that input looked like this:

There were two recurring complaints regarding this specific implementation. The first was that participants felt they had to align their rating to one of the labels beneath the slider track. This was undesirable for the simple fact that the slider was chosen specifically to encourage participants to provide nuanced assessments.

The second complaint was that the submit button was disabled until the user interacted with the slider. This design choice was intended to prevent participants from simply clicking the submit button on every page without rating images. Unfortunately, this implementation was unintentionally hostile to the user and needed improvement, because it blocked users from rating images without a clear and obvious explanation as to why.

Fixing the problem with the labels meant redesigning the slider as it appeared in Figure 3. I removed the labels altogether to eliminate the temptation of users to align their answers to them. Additionally, I changed the slider background property to a gradient pattern, which further implied the granularity of the input.

The submit button issue was a matter of how users were prompted. In round one the submit button was visible, yet the disabled state wasn’t obvious enough to some. After consulting with a colleague, I found a solution for round two: in lieu of the submit button being initially visible, it’s hidden by some guide copy:

Once the user interacts with the slider and rates the image, a change event attached to the input fires, which hides the guide copy and replaces it with the submit button:

This solution is less ambiguous, and it funnels participants down the desired path. If someone with JavaScript disabled visits, the guide copy is never shown, and the submit button is immediately usable. This isn’t ideal, but it doesn’t shut out participants without JavaScript.

Addressing scrolling woes

The survey page works especially well in portrait orientation. Participants can see all (or most) of the image without needing to scroll. In browser windows or mobile devices in landscape orientation, however, the survey image can be larger than the viewport:

Working with such limited vertical real estate is tricky, especially in this case where the slider needs to be fixed to the bottom of the screen (which addressed an earlier bit of user feedback from round one testing). After discussing the issue with colleagues, I decided that animated indicators in the corners of the page could signal to users that there’s more of the image to see.

When the user hits the bottom of the page, the scroll indicators disappear. Because animations may be jarring for certain users, a prefers-reduced-motion media query is used to turn off this (and all other) animations if the user has a stated preference for reduced motion. In the event JavaScript is disabled, the scrolling indicators are always hidden in portrait orientation where they’re less likely to be useful and always visible in landscape where they’re potentially needed the most.

Avoiding overscaling of image specimens

One issue that was brought to my attention from a coworker was how the survey image seemed to expand boundlessly with the viewport. On mobile devices this isn’t such a problem, but on large screens and even modestly sized high-density displays, images can be scaled excessively. Because the responsive img tag’s srcset attribute specifies a maximum resolution image of 1536w, an image can begin to overscale at as “small” at sizes over 768 pixels wide on devices with a device pixel ratio of 2.

Some overscaling is inevitable and acceptable. However, when it’s excessive, compression artifacts in an image can become more pronounced. To address this, the survey image’s max-width is set to 1536px for standard displays as of round two. For devices with a device pixel ratio of 2 or higher, the survey image’s max-width is set to half that at 768px:

This minor (yet important) fix ensures that images aren’t scaled beyond a reasonable maximum. With a reasonably sized image asset in the viewport, participants will assess images close to or at a given image asset’s natural dimensions, particularly on large screens.

User feedback is valuable. These and other UX feedback items I incorporated improved both the function of the survey and the integrity of the collected data. All it took was sitting down with users and listening to them.

Wrapping up

As round two of the survey gets under way, I’m hoping the data gathered reveals something exciting about the relationship between performance and how people perceive image quality. If you want to be a part of the effort, please take the survey. When round two concludes, keep an eye out here for a summary of the results!

Thank you to those who gave their valuable time and feedback to make this article as good as it could possibly be: Aaron Gustafson, Jeffrey Zeldman, Brandon Gregory, Rachel Andrew, Bruce Hyslop, Adrian Roselli, Meg Dickey-Kurdziolek, and Nick Tucker.

Additional thanks to those who helped improve the image quality survey: Mandy Tensen, Darleen Denno, Charlotte Dann, Tim Dunklee, and Thad Roe.

Categories: Technology

In the news

iPhone J.D. - Sat, 03/17/2018 - 00:19

As noted by Dan Moren of Six Colors, Apple announced this week that it is having an event March 27 in Chicago.  The event will take place at a school, and Apple is calling it a Field Trip, so I imagine that Apple will be showing off some new technology that can be used in education.  But that doesn't mean that it might not also be useful for lawyers.  For example, my Apple Pencil is one of the most useful Apple products in my law practice, and as Serenity Caldwell of iMore notes, one rumor is that Apple could debut an Apple Pencil 2 at the event.  Other folks are predicting a new iPad will be announced, although that one seems a little more far-fetched to me.  At this point we can only speculate what will be announced, but if you were planning to buy an Apple product in the next 10 days, you might consider waiting until March 27 just in case Apple updates the product that you were thinking about buying.  And now, the news of note from the past week:

  • My favorite app for listening to podcasts is Overcast because it has so many great features.  This week the app added a new feature called Smart Resume, so that when you pause the podcast and then subsequently resume, the podcast backs up a few seconds and finds dead space between words and starts there.  Chicago attorney John Voorhees of MacStories describes the new feature.  It's so clever that you instantly wonder why podcast apps haven't always done this.
  • Massachusetts attorney Bob Amborgi reports that with Kentucky adding the requirement, there are now 30 states which have an ethical rule imposing a duty of technological competence on attorneys.
  • Oklahoma City attorney Jeff Taylor of the Droid Lawyer website explains how you can manage the information that Google has about you using the MyAccount feature.
  • Earlier this week, I discussed the recent ABA TECHSHOW conference, and one of the things that I mentioned was that the conference iPhone app was quite good.  New York attorney Nicole Black had the same thought, and write about how a good app can help a conference in this article for Above the Law.
  • When you exercise with your Apple Watch, the watch keeps track of your heart rate during the workout.  But what if you want to keep track of your heart rate when you are not working out?  Chance Miller of 9to5Mac describes the HeartMonitor app for Apple Watch which allows you to start a non-exercise session in which the watch will track your heart rate.
  • Many cities now have a bike sharing option that you can pay for.  Romain Dillet of TechCrunch notes that Apple Maps now has the ability to show you the nearest bike-sharing stations in many cities, including 24 U.S. cities and many other around the world.  In New Orleans where I live, we have a relatively new bike sharing service called Blue Bikes and I see people using the service all the time, but Apple Maps doesn't yet work with that service.
  • If you ever thought that you could redact a PDF document using the iOS built-in Markup feature, Benjamin Mayo of 9to5Mac explains why this is NOT an appropriate way to redact confidential information.
  • There is something funny about buying an accessory for an accessory, but that doesn't mean that it isn't useful.  Serenity Caldwell of iMore discusses some of the best accessories for the Apple Pencil.
  • There are lots of ways that you can manage multiple iPhones and other Apple products within a family.  This week, Apple unveiled a new Families page on its website to show you everything that you can do.
  • If you use iAnnotate by Branchfire to manage and annotate your PDF files, a post on the Branchfire blog describes the version 4.5 update which adds the ability to merge PDFs and other features.
  • If you want to add CarPlay to a car which doesn't have it, Zac Hall of 9to5Mac recommends the best aftermarket CarPlay receivers.
  • And finally, this week Apple unveiled a fun commercial called Unlock which shows off the power of using Face ID to unlock an iPhone X.  I like this one:

Categories: iPhone Web Sites

IBM Spectrum Archive Enterprise Edition V1.2.6 Installation and Configuration Guide

IBM Redbooks Site - Fri, 03/16/2018 - 09:30
Draft Redbook, last updated: Fri, 16 Mar 2018

This IBM® Redbooks® publication helps you with the planning, installation, and configuration of the new IBM Spectrum™ Archive Enterprise Edition V1.2.6 for the IBM TS3310, IBM TS3500, IBM TS4300, and IBM TS4500 tape libraries.

Categories: Technology

LDAP Authentication for IBM DS8000 Systems

IBM Redbooks Site - Fri, 03/16/2018 - 09:30
Redpaper, published: Fri, 16 Mar 2018

The IBM® DS8000® series includes the option to replace the locally based user ID and password authentication with a centralized directory-based approach.

Categories: Technology

Conversational Design

A list Apart development site - Thu, 03/15/2018 - 10:30

A note from the editors: We’re pleased to share an excerpt from Chapter 1 of Erika Hall’s new book, Conversational Design, available now from A Book Apart.

Texting is how we talk now. We talk by tapping tiny messages on touchscreens—we message using SMS via mobile data networks, or through apps like Facebook Messenger or WhatsApp.

.article-layout .main-content > figure.quote:first-child figcaption { margin-top: 1rem; }

In 2015, the Pew Research Center found that 64% of American adults owned a smartphone of some kind, up from 35% in 2011. We still refer to these personal, pocket-sized computers as phones, but “Phone” is now just one of many communication apps we neglect in favor of texting. Texting is the most widely used mobile data service in America. And in the wider world, four billion people have mobile phones, so 4 billion people have access to SMS or other messaging apps. For some, dictating messages into a wristwatch offers an appealing alternative to placing a call.

The popularity of texting can be partially explained by the medium’s ability to offer the easy give-and-take of conversation without requiring continuous attention. Texting feels like direct human connection, made even more captivating by unpredictable lag and irregular breaks. Any typing is incidental because the experience of texting barely resembles “writing,” a term that carries associations of considered composition. In his TED talk, Columbia University linguist John McWhorter called texting “fingered conversation”—terminology I find awkward, but accurate. The physical act—typing—isn’t what defines the form or its conventions. Technology is breaking down our traditional categories of communication.

By the numbers, texting is the most compelling computer-human interaction going. When we text, we become immersed and forget our exchanges are computer-mediated at all. We can learn a lot about digital design from the inescapable draw of these bite-sized interactions, specifically the use of language.

What Texting Teaches Us

This is an interesting example of what makes computer-mediated interaction interesting. The reasons people are compelled to attend to their text messages—even at risk to their own health and safety—aren’t high-production values, so-called rich media, or the complexity of the feature set.

Texting, and other forms of social media, tap into something very primitive in the human brain. These systems offer always-available social connection. The brevity and unpredictability of the messages themselves triggers the release of dopamine that motivates seeking behavior and keeps people coming back for more. What makes interactions interesting may start on a screen, but the really interesting stuff happens in the mind. And language is a critical part of that. Our conscious minds are made of language, so it’s easy to perceive the messages you read not just as words but as the thoughts of another mingled with your own. Loneliness seems impossible with so many voices in your head.

With minimal visual embellishment, texts can deliver personality, pathos, humor, and narrative. This is apparent in “Texts from Dog,” which, as the title indicates, is a series of imagined text exchanges between a man and his dog. (Fig 1.1). With just a few words, and some considered capitalization, Joe Butcher (writing as October Jones) creates a vivid picture of the relationship between a neurotic canine and his weary owner.

Fig 1.1: “Texts from Dog” shows how lively a simple text exchange can be.

Using words is key to connecting with other humans online, just as it is in the so-called “real world.” Imbuing interfaces with the attributes of conversation can be powerful. I’m far from the first person to suggest this. However, as computers mediate more and more relationships, including customer relationships, anyone thinking about digital products and services is in a challenging place. We’re caught between tried-and-true past practices and the urge to adopt the “next big thing,” sometimes at the exclusion of all else.

Being intentionally conversational isn’t easy. This is especially true in business and at scale, such as in digital systems. Professional writers use different types of writing for different purposes, and each has rules that can be learned. The love of language is often fueled by a passion for rules — rules we received in the classroom and revisit in manuals of style, and rules that offer writers the comfort of being correct outside of any specific context. Also, there is the comfort of being finished with a piece of writing and moving on. Conversation, on the other hand, is a context-dependent social activity that implies a potentially terrifying immediacy.

Moving from the idea of publishing content to engaging in conversation can be uncomfortable for businesses and professional writers alike. There are no rules. There is no done. It all feels more personal. Using colloquial language, even in “simplifying” interactive experiences, can conflict with a desire to appear authoritative. Or the pendulum swings to the other extreme and a breezy style gets applied to a laborious process like a thin coat of paint.

As a material for design and an ingredient in interactions, words need to emerge from the content shed and be considered from the start.  The way humans use language—easily, joyfully, sometimes painfully—should anchor the foundation of all interactions with digital systems.

The way we use language and the way we socialize are what make us human; our past contains the key to what commands our attention in the present, and what will command it in the future. To understand how we came to be so perplexed by our most human quality, it’s worth taking a quick look at, oh!, the entire known history of communication technology.

The Mother Tongue

Accustomed to eyeballing type, we can forget language began in our mouths as a series of sounds, like the calls and growls of other animals. We’ll never know for sure how long we’ve been talking—speech itself leaves no trace—but we do know it’s been a mighty long time.

Archaeologist Natalie Thais Uomini and psychologist Georg Friedrich Meyer concluded that our ancestors began to develop language as early as 1.75 million years ago. Per the fossil record, modern humans emerged at least 190,000 years ago in the African savannah. Evidence of cave painting goes back 30,000 years (Fig 1.2).

Then, a mere 6,000 years ago, ancient Sumerian commodity traders grew tired of getting ripped off. Around 3200 BCE, one of them had the idea to track accounts by scratching wedges in wet clay tablets. Cuneiform was born.

So, don’t feel bad about procrastinating when you need to write—humanity put the whole thing off for a couple hundred thousand years! By a conservative estimate, we’ve had writing for about 4% of the time we’ve been human. Chatting is easy; writing is an arduous chore.

Prior to mechanical reproduction, literacy was limited to the elite by the time and cost of hand-copying manuscripts. It was the rise of printing that led to widespread literacy; mass distribution of text allowed information and revolutionary ideas to circulate across borders and class divisions. The sharp increase in literacy bolstered an emerging middle class. And the ability to record and share knowledge accelerated all other advances in technology: photography, radio, TV, computers, internet, and now the mobile web. And our talking speakers.

Fig 1.2: In hindsight, “literate culture” now seems like an annoying phase we had to go through so we could get to texting.

Every time our communication technology advances and changes, so does the surrounding culture—then it disrupts the power structure and upsets the people in charge. Catholic archbishops railed against mechanical movable type in the fifteenth century. Today, English teachers deplore texting emoji. Resistance is, as always, futile. OMG is now listed in the Oxford English Dictionary.

But while these developments have changed the world and how we relate to one another, they haven’t altered our deep oral core.

Orality, Say It with Me Orality knits persons into community. Walter Ong

Today, when we record everything in all media without much thought, it’s almost impossible to conceive of a world in which the sum of our culture existed only as thoughts.

Before literacy, words were ephemeral and all knowledge was social and communal. There was no “save” option and no intellectual property. The only way to sustain an idea was to share it, speaking aloud to another person in a way that made it easy for them to remember. This was orality—the first interface.

We can never know for certain what purely oral cultures were like. People without writing are terrible at keeping records. But we can examine oral traditions that persist for clues.

The oral formula

Reading and writing remained elite activities for centuries after their invention. In cultures without a writing system, oral characteristics persisted to help transmit poetry, history, law and other knowledge across generations.

The epic poems of Homer rely on meter, formulas, and repetition to aid memory:

Far as a man with his eyes sees into the mist of the distance Sitting aloft on a crag to gaze over the wine-dark seaway, Just so far were the loud-neighing steeds of the gods overleaping. Iliad, 5.770

Concrete images like rosy-fingered dawn, loud-neighing steeds, wine-dark seaway, and swift-footed Achilles served to aid the teller and to sear the story into the listener’s memory.

Biblical proverbs also encode wisdom in a memorable format:

As a dog returns to its vomit, so fools repeat their folly. Proverbs 26:11

That is vivid.

And a saying that originated in China hundreds of years ago can prove sufficiently durable to adorn a few hundred Etsy items:

A journey of a thousand miles begins with a single step. Tao Te Ching, Chapter 64, ascribed to Lao Tzu The labor of literature

Literacy created distance in time and space and decoupled shared knowledge from social interaction. Human thought escaped the existential present. The reader doesn’t need to be alive at the same time as the writer, let alone hanging out around the same fire pit or agora. 

Freed from the constraints of orality, thinkers explored new forms to preserve their thoughts. And what verbose and convoluted forms these could take:

The Reader will I doubt too soon discover that so large an interval of time was not spent in writing this discourse; the very length of it will convince him, that the writer had not time enough to make a shorter. George Tullie, An Answer to a Discourse Concerning the Celibacy of the Clergy, 1688

There’s no such thing as an oral semicolon. And George Tullie has no way of knowing anything about his future audience. He addresses himself to a generic reader he will never see, nor receive feedback from. Writing in this manner is terrific for precision, but not good at all for interaction.

Writing allowed literate people to become hermits and hoarders, able to record and consume knowledge in total solitude, invest authority in them, and defend ownership of them. Though much writing preserved the dullest of records, the small minority of language communities that made the leap to literacy also gained the ability to compose, revise, and perfect works of magnificent complexity, utility, and beauty.

The qualities of oral culture

In Orality and Literacy: The Technologizing of the Word, Walter Ong explored the “psychodynamics of orality,” which is, coincidentally, quite a mouthful.  Through his research, he found that the ability to preserve ideas in writing not only increased knowledge, it altered values and behavior. People who grow up and live in a community that has never known writing are different from literate people—they depend upon one another to preserve and share knowledge. This makes for a completely different, and much more intimate, relationship between ideas and communities.

Oral culture is immediate and social

In a society without writing, communication can happen only in the moment and face-to-face. It sounds like the introvert’s nightmare! Oral culture has several other hallmarks as well:

  • Spoken words are events that exist in time. It’s impossible to step back and examine a spoken word or phrase. While the speaker can try to repeat, there’s no way to capture or replay an utterance.
  • All knowledge is social, and lives in memory. Formulas and patterns are essential to transmitting and retaining knowledge. When the knowledge stops being interesting to the audience, it stops existing.
  • Individuals need to be present to exchange knowledge or communicate. All communication is participatory and immediate. The speaker can adjust the message to the context. Conversation, contention, and struggle help to retain this new knowledge.
  • The community owns knowledge, not individuals. Everyone draws on the same themes, so not only is originality not helpful, it’s nonsensical to claim an idea as your own.
  • There are no dictionaries or authoritative sources. The right use of a word is determined by how it’s being used right now.
Literate culture promotes authority and ownership

Printed books enabled mass-distribution and dispensed with handicraft of manuscripts, alienating readers from the source of the ideas, and from each other. (Ong pg. 100):

  • The printed text is an independent physical object. Ideas can be preserved as a thing, completely apart from the thinker.
  • Portable printed works enable individual consumption. The need and desire for private space accompanied the emergence of silent, solo reading.
  • Print creates a sense of private ownership of words. Plagiarism is possible.
  • Individual attribution is possible. The ability to identify a sole author increases the value of originality and creativity.
  • Print fosters a sense of closure. Once a work is printed, it is final and closed.

Print-based literacy ascended to a position of authority and cultural dominance, but it didn’t eliminate oral culture completely.

Technology brought us together again

All that studying allowed people to accumulate and share knowledge, speeding up the pace of technological change. And technology transformed communication in turn. It took less than 150 years to get from the telegraph to the World Wide Web. And with the web—a technology that requires literacy—Ong identified a return to the values of the earlier oral culture. He called this secondary orality. Then he died in 2003, before the rise of the mobile internet, when things really got interesting.

Secondary orality is:

  • Immediate. There is no necessary delay between the expression of an idea and its reception. Physical distance is meaningless.
  • Socially aware and group-minded. The number of people who can hear and see the same thing simultaneously is in the billions.
  • Conversational. This is in the sense of being both more interactive and less formal.
  • Collaborative. Communication invites and enables a response, which may then become part of the message.
  • Intertextual. The products of our culture reflect and influence one another.

Social, ephemeral, participatory, anti-authoritarian, and opposed to individual ownership of ideas—these qualities sound a lot like internet culture.

Wikipedia: Knowledge Talks

When someone mentions a genre of music you’re unfamiliar with—electroclash, say, or plainsong—what do you do to find out more? It’s quite possible you type the term into Google and end up on Wikipedia, the improbably successful, collaborative encyclopedia that would be absent without the internet.

According to Wikipedia, encyclopedias have existed for around two-thousand years. Wikipedia has existed since 2001, and it’s the fifth most-popular site on the web. Wikipedia is not a publication so much as a society that provides access to knowledge. A volunteer community of “Wikipedians” continuously adds to and improves millions of articles in over 200 languages. It’s a phenomenon manifesting all the values of secondary orality:

  • Anyone can contribute anonymously and anyone can modify the contributions of another.
  • The output is free.
  • The encyclopedia articles are not attributed to any sole creator. A single article might have 2 editors or 1,000.
  • Each article has an accompanying “talk” page where editors discuss potential improvements, and a “history” page that tracks all revisions. Heated arguments are not documented. They take place as revisions within documents.

Wikipedia is disruptive in the true Clayton Christensen sense. It’s created immense value and wrecked an existing business model. Traditional encyclopedias are publications governed by authority, and created by experts and fact checkers. A volunteer project collaboratively run by unpaid amateurs shows that conversation is more powerful than authority, and that human knowledge is immense and dynamic.

In an interview with The Guardian, a British librarian expressed some disdain about Wikipedia.

The main problem is the lack of authority. With printed publications, the publishers must ensure that their data are reliable, as their livelihood depends on it. But with something like this, all that goes out the window. Philip Bradley, “Who knows?”, The Guardian, October 26, 2004

Wikipedia is immediate, group-minded, conversational, collaborative, and intertextual— secondary orality in action—but it relies on traditionally published sources for its authority. After all, anything new that changes the world does so by fitting into the world. As we design for new methods of communication, we should remember that nothing is more valuable simply because it’s new; rather, technology is valuable when it brings us more of what’s already meaningful.

From Documents to Events

Pages and documents organize information in space. Space used to be more of a constraint back when we printed conversation out. Now that the internet has given us virtually infinite space, we need to mind how conversation moves through time. Thinking about serving the needs of people in an internet-based culture requires a shift from thinking about how information occupies space—documents—to how it occupies time—events.

Texting means that we’ve never been more lively (yet silent) in our communications. While we still have plenty of in-person interactions, it’s gotten easy to go without. We text grocery requests to our spouses. We click through a menu in a mobile app to summon dinner (the order may still arrive at the restaurant by fax, proving William Gibson’s maxim that the future is unevenly distributed). We exchange messages on Twitter and Facebook instead of visiting friends in person, or even while visiting friends in person. We work at home and Slack our colleagues.

We’re rapidly approaching a future where humans text other humans and only speak aloud to computers. A text-based interaction with a machine that’s standing in for a human should feel like a text-based interaction with a human. Words are a fundamental part of the experience, and they are part of the design. Words should be the basis for defining and creating the design.

We’re participating in a radical cultural transformation. The possibilities manifest in systems like Wikipedia that succeed in changing the world by using technology to connect people in a single collaborative effort. And even those of us creating the change suffer from some lag. The dominant educational and professional culture remains based in literary values. We’ve been rewarded for individual achievement rather than collaboration. We seek to “make our mark,” even when designing changeable systems too complex for any one person to claim authorship. We look for approval from an authority figure. Working in a social, interactive way should feel like the most natural thing in the world, but it will probably take some doing.

Literary writing—any writing that emerges from the culture and standards of literacy—is inherently not interactive. We need to approach the verbal design not as a literary work, but as a conversation. Designing human-centered interactive systems requires us to reflect on our deep-seated orientation around artifacts and ownership. We must alienate ourselves from a set of standards that no longer apply.

Most advice on “writing for the web” or “creating content” starts from the presumption that we are “writing,” just for a different medium. But when we approach communication as an assembly of pieces of content rather than an interaction, customers who might have been expecting a conversation end up feeling like they’ve been handed a manual instead.

Software is on a path to participating in our culture as a peer.  So, it should behave like a person—alive and present. It doesn’t matter how much so-called machine intelligence is under the hood—a perceptive set of programmatic responses, rather than a series of documents, can be enough if they have the qualities of conversation.

Interactive systems should evoke the best qualities of living human communities—active, social, simple, and present—not passive, isolated, complex, or closed off.

Life Beyond Literacy Indeed, language changes lives. It builds society, expresses our highest aspirations, our basest thoughts, our emotions and our philosophies of life. But all language is ultimately at the service of human interaction. Other components of language—things like grammar and stories—are secondary to conversation. Daniel L. Everett, How Language Began

Literacy has gotten us far. It’s gotten you this far in this book. So, it’s not surprising we’re attached to the idea. Writing has allowed us to create technologies that give us the ability to interact with one another across time and space, and have instantaneous access to knowledge in a way our ancestors would equate with magic. However, creating and exchanging documents, while powerful, is not a good model for lively interaction. Misplaced literate values can lead to misery—working alone and worrying too much about posterity.

So, it’s time to let go and live a little! We’re at an exciting moment. The computer screen that once stood for a page can offer a window into a continuous present that still remembers everything. Or, the screen might disappear completely.

Now we can start imagining, in an open-ended way, what constellation of connected devices any given person will have around them, and how we can deliver a meaningful, memorable experience on any one of them. We can step away from the screen and consider what set of inputs, outputs, events, and information add up to the best experience.

This is daunting for designers, sure, yet phenomenal for people. Thinking about human-computer interactions from a screen-based perspective was never truly human-centered from the start. The ideal interface is an interface that’s not noticeable at all—a world in which the distance from thought to action has collapsed and merely uttering a phrase can make it so.

We’re fast moving past “computer literacy.” It’s on us to ensure all systems speak human fluently.

Categories: Technology

IBM CICS Performance Series: CICS TS for z/OS V5 Performance Report

IBM Redbooks Site - Thu, 03/15/2018 - 09:30
Redbook, published: Thu, 15 Mar 2018

This IBM Redbooks® publication gives a broad understanding of several important concepts that are used when describing IBM CICS Transaction Server (TS) for IBM z/OS (CICS TS) performance.

Categories: Technology

DRI Appellate Advocacy Seminar

iPhone J.D. - Wed, 03/14/2018 - 01:05

I usually try to avoid attending conferences two weeks in a row, but appellate law is a significant part of my law practice, and there is a big appellate conference going on this week.  Thus, after attending ABA TECHSHOW last week, this week I'm attending the DRI Appellate Advocacy Seminar in Las Vegas. 

I know from the emails I receive that lots of appellate lawyers read iPhone J.D.  If you are attending the seminar this week, please look for me and say hello.  (This is what I look like.)  I'd especially love to learn about how you are using an iPad in your appellate practice, either during the briefing stage or for oral argument.  Or if you have advice on whether I should bet on black or red, that could be helpful too.

Categories: iPhone Web Sites

IBM FlashSystem V9000 Version 8.1 Product Guide

IBM Redbooks Site - Tue, 03/13/2018 - 09:30
Draft Redpaper, last updated: Tue, 13 Mar 2018

This IBM Redbooks® Product Guide describes IBM FlashSystem® V9000, which is a comprehensive all-flash enterprise storage solution that delivers the full capabilities of IBM FlashCore™ technology.

Categories: Technology

A DIY Web Accessibility Blueprint

A list Apart development site - Tue, 03/13/2018 - 09:18

The summer of 2017 marked a monumental victory for the millions of Americans living with a disability. On June 13th, a Southern District of Florida Judge ruled that Winn-Dixie’s inaccessible website violated Title III of the Americans with Disabilities Act. This case marks the first trial under the ADA, which was passed into law in 1990.

Despite spending more than $7 million to revamp its website in 2016, Winn-Dixie neglected to include design considerations for users with disabilities. Some of the features that were added include online prescription refills, digital coupons, rewards card integration, and a store locator function. However, it appears that inclusivity didn’t make the cut.

Because Winn-Dixie’s new website wasn’t developed to WCAG 2.0 standards, the new features it boasted were in effect only available to sighted, able-bodied users. When Florida resident Juan Carlos Gil, who is legally blind, visited the Winn-Dixie website to refill his prescriptions, he found it to be almost completely inaccessible using the same screen reader software he uses to access hundreds of other sites.

Juan stated in his original complaint that he “felt as if another door had been slammed in his face.” But Juan wasn’t alone. Intentionally or not, Winn-Dixie was denying an entire group of people access to their new website and, in turn, each of the time-saving features it had to offer.

What makes this case unique is that it marks the first time in history in which a public accommodations case went to trial, meaning the judge ruled the website to be a “place of a public accommodation” under the ADA and therefore subject to ADA regulations. Since there are no specific ADA regulations regarding the internet, Judge Scola decided the adoption of the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA to be appropriate. (Thanks to the hard work of the Web Accessibility Initiative (WAI) at the W3C, WCAG 2.0 has found widespread adoption throughout the globe, either as law or policy.)

Learning to have empathy

Anyone with a product subscription service (think diapers, razors, or pet food) knows the feeling of gratitude that accompanies the delivery of a much needed product that arrives just in the nick of time. Imagine how much more grateful you’d be for this service if you, for whatever reason, were unable to drive and lived hours from the nearest store. It’s a service that would greatly improve your life. But now imagine that the service gets overhauled and redesigned in such a way that it is only usable by people who own cars. You’d probably be pretty upset.

This subscription service example is hypothetical, yet in the United States, despite federal web accessibility requirements instituted to protect the rights of disabled Americans, this sort of discrimination happens frequently. In fact, anyone assuming the Winn-Dixie case was an isolated incident would be wrong. Web accessibility lawsuits are rising in number. The increase from 2015 to 2016 was 37%. While some of these may be what’s known as “drive-by lawsuits,” many of them represent plaintiffs like Juan Gil who simply want equal rights. Scott Dinin, Juan’s attorney, explained, “We’re not suing for damages. We’re only suing them to follow the laws that have been in this nation for twenty-seven years.”

For this reason and many others, now is the best time to take a proactive approach to web accessibility. In this article I’ll help you create a blueprint for getting your website up to snuff.

The accessibility blueprint

If you’ll be dealing with remediation, I won’t sugarcoat it: successfully meeting web accessibility standards is a big undertaking, one that is achieved only when every page of a site adheres to all the guidelines you are attempting to comply with. As I mentioned earlier, those guidelines are usually WCAG 2.0 Level AA, which means meeting every Level A and AA requirement. Tight deadlines, small budgets, and competing priorities may increase the stress that accompanies a web accessibility remediation project, but with a little planning and research, making a website accessible is both reasonable and achievable.

My intention is that you may use this article as a blueprint to guide you as you undertake a DIY accessibility remediation project. Before you begin, you’ll need to increase your accessibility know-how, familiarize yourself with the principles of universal design, and learn about the benefits of an accessible website. Then you may begin to evangelize the benefits of web accessibility to those you work with.

Have the conversation with leadership

Securing support from company leadership is imperative to the long-term success of your efforts. There are numerous ways to broach the subject of accessibility, but, sadly, in the world of business, substantiated claims top ethics and moral obligation. Therefore I’ve found one of the most effective ways to build a business case for web accessibility is to highlight the benefits.

Here are just a few to speak of:

  • Accessible websites are inherently more usable, and consequently they get more traffic. Additionally, better user experiences result in lower bounce rates, higher conversions, and less negative feedback, which in turn typically make accessible websites rank higher in search engines.
  • Like assistive technology, web crawlers (such as Googlebot) leverage HTML to get their information from websites, so a well marked-up, accessible website is easier to index, which makes it easier to find in search results.
  • There are a number of potential risks for not having an accessible website, one of which is accessibility lawsuits.
  • Small businesses in the US that improve the accessibility of their website may be eligible for a tax credit from the IRS.
Start the movement

If you can’t secure leadership backing right away, you can still form a grassroots accessibility movement within the company. Begin slowly and build momentum as you work to improve usability for all users. Though you may not have the authority to make company-wide changes, you can strategically and systematically lead the charge for web accessibility improvements.

My advice is to start small. For example, begin by pushing for site-wide improvements to color contrast ratios (which would help color-blind, low-vision, and aging users) or work on making the site keyboard accessible (which would help users with mobility impairments or broken touchpads, and people such as myself who prefer not using a mouse whenever possible). Incorporate user research and A/B testing into these updates, and document the results. Use the results to champion for more accessibility improvements.

Read and re-read the guidelines

Build your knowledge base as you go. Learning which laws, rules, or guidelines apply to you, and understanding them, is a prerequisite to writing an accessibility plan. Web accessibility guidelines vary throughout the world. There may be other guidelines that apply to you, and in some cases, additional rules, regulations, or mandates specific to your industry.

Not understanding which rules apply to you, not reading them in full, or not understanding what they mean can create huge problems down the road, including excessive rework once you learn you need to make changes.

Build a team

Before you can start remediating your website, you’ll need to assemble a team. The number of people will vary depending on the size of your organization and website. I previously worked for a very large company with a very large website, yet the accessibility team they assembled was small in comparison to the thousands of pages we were tasked to remediate. This team included a project manager, visual designers, user experience designers, front-end developers, content editors, a couple requirements folks, and a few QA testers. Most of these people had been pulled from their full-time roles and instructed to quickly become familiar with WCAG 2.0. To help you create your own accessibility team, I will explain in detail some of the top responsibilities of the key players:

  • Project manager is responsible for coordinating the entire remediation process. They will help run planning sessions, keep everyone on schedule, and report the progress being made. Working closely with the requirements people, their goal is to keep every part of this new machine running smoothly.
  • Visual designers will mainly address issues of color usage and text alternatives. In its present form, WCAG 2.0 contrast minimums only apply to text, however the much anticipated WCAG 2.1 update (due to be released in mid-2018) contains a new success criterion for Non-text Contrast, which covers contrast minimums of all interactive elements and “graphics required to understand the content.” Visual designers should also steer clear of design trends that ruin usability.
  • UX designers should be checking for consistent, logical navigation and reading order. They’ll need to test that pages are using heading tags appropriately (headings are for semantic structure, not for visual styling). They’ll be checking to see that page designs are structured to appear and operate in predictable ways.
  • Developers have the potential to make or break an accessible website because even the best designs will fail if implemented incorrectly. If your developers are unfamiliar with WAI-ARIA, accessible coding practices, or accessible JavaScript, then they have a few things to learn. Developers should think of themselves as designers because they play a very important role in designing an inclusive user experience. Luckily, Google offers a short, free Introduction to Web Accessibility course and, via Udacity, a free, advanced two-week accessibility course. Additionally, The A11Y Project is a one-stop shop loaded with free pattern libraries, checklists, and accessibility resources for front-end developers.
  • Editorial review the copy for verbosity. Avoid using phrases that will confuse people who aren’t native language speakers. Don’t “beat around the bush” (see what I did there?). Keep content simple, concise, and easy to understand. No writing degree? No worries. There are apps that can help you improve the clarity of your writing and that correct your grammar like a middle school English teacher. Score bonus points by making sure link text is understandable out of context. While this is a WCAG 2.0 Level AAA guideline, it’s also easily fixed and it greatly improves the user experience for individuals with varying learning and cognitive abilities.
  • Analysts work in tandem with editorial, design, UX, and QA. They coordinate the work being done by these groups and document the changes needed. As they work with these teams, they manage the action items and follow up on any outstanding tasks, questions, or requests. The analysts also deliver the requirements specifications to the developers. If the changes are numerous and complex, the developers may need the analysts to provide further clarification and to help them properly implement the changes as described in the specs.
  • QA will need to be trained to the same degree as the other accessibility specialists since they will be responsible for testing the changes that are being made and catching any issues that arise. They will need to learn how to navigate a website using only a keyboard and also by properly using a screen reader (ideally a variety of screen readers). I emphasized “properly” because while anyone can download NVDA or turn on VoiceOver, it takes another level of skill to understand the difference between “getting through a page” and “getting through a page with standard keyboard controls.” Having individuals with visual, auditory, or mobility impairments on the QA team can be a real advantage, as they are more familiar with assistive technology and can test in tandem with others. Additionally, there are a variety of automated accessibility testing tools you can use alongside manual testing. These tools typically catch only around 30% of common accessibility issues, so they do not replace ongoing human testing. But they can be extremely useful in helping QA learn when an update has negatively affected the accessibility of your website.
Start your engines!

Divide your task into pieces that make sense. You may wish to tackle all the global elements first, then work your way through the rest of the site, section by section. Keep in mind that every page must adhere to the accessibility standards you’re following for it to be deemed “accessible.” (This includes PDFs.)

Use what you’ve learned so far by way of accessibility videos, articles, and guidelines to perform an audit of your current site. While some manual testing may seem difficult at first, you’ll be happy to learn that some manual testing is very simple. Regardless of the testing being performed, keep in mind that it should always be done thoroughly and by considering a variety of users, including:

  • keyboard users;
  • blind users;
  • color-blind users;
  • low-vision users;
  • deaf and hard-of-hearing users;
  • users with learning disabilities and cognitive limitations;
  • mobility-impaired users;
  • users with speech disabilities;
  • and users with seizure disorders.
When you are in the weeds, document the patterns

As you get deep in the weeds of remediation, keep track of the patterns being used. Start a knowledge repository for elements and situations. Lock down the designs and colors, code each element to be accessible, and test these patterns across various platforms, browsers, screen readers, and devices. When you know the elements are bulletproof, save them in a pattern library that you can pull from later. Having a pattern library at your fingertips will improve consistency and compliance, and help you meet tight deadlines later on, especially when working in an agile environment. You’ll need to keep this online knowledge repository and pattern library up-to-date. It should be a living, breathing document.

Cross the finish line … and keep going!

Some people mistakenly believe accessibility is a set-it-and-forget-it solution. It isn’t. Accessibility is an ongoing challenge to continually improve the user experience the way any good UX practitioner does. This is why it’s crucial to get leadership on board. Once your site is fully accessible, you must begin working on the backlogs of continuous improvements. If you aren’t vigilant about accessibility, people making even small site updates can unknowingly strip the site of the accessibility features you worked so hard to put in place. You’d be surprised how quickly it can happen, so educate everyone you work with about the importance of accessibility. When everyone working on your site understands and evangelizes accessibility, your chances of protecting the accessibility of the site are much higher.

It’s about the experience, not the law

In December of 2017, Winn-Dixie appealed the case with blind patron Juan Carlo Gil. Their argument is that a website does not constitute a place of accommodation, and therefore, their case should have been dismissed. This case, and others, illustrate that the legality of web accessibility is still very much in flux. However, as web developers and designers, our motivation to build accessible websites should have nothing to do with the law and everything to do with the user experience.

Good accessibility is good UX. We should seek to create the best user experience for all. And we shouldn’t settle for simply meeting accessibility standards but rather strive to create an experience that delights users of all abilities.

Additional resources and articles

If you are ready to learn more about web accessibility standards and become the accessibility evangelist on your team, here are some additional resources that can help.

Resources Articles
Categories: Technology

Reflections on ABA TECHSHOW 2018

iPhone J.D. - Sun, 03/11/2018 - 21:31

Last week, I attended ABA TECHSHOW 2018.  For decades, this event held in Chicago every Spring has been the biggest and best event for learning more about legal technology — in other words, for about as long as legal technology has even been a thing.  Every TECHSHOW is different, and there were some big differences this year, most notably a new venue at the Chicago Hyatt Regency.  Debbie Foster and Tom Mighell were the co-chairs of TECHSHOW this year, and they and the rest of the planning board deserve lots of praise for making this transition work so well.  Pretty much every aspect of the venue was better this year.  The layout of the Expo Hall was particularly improved, with everything together in one huge space.  And it was nice having the conference rooms much closer to the Expo Hall so you could more easily go back-and-forth.

The iPhone app associated with the conference was also great this year.  It contained the full schedule and made it easy to create your own agenda of the events and sessions you want to attend.  You could see all program materials.  You could get information on speakers and attendees.  And there was a nice integrated social component with pictures and information, a fun way to see what people were doing without having to do a search on Twitter.  I wish that the app had been updated to accommodate the larger iPhone X screen, but otherwise, it was a great companion for the conference and made printed materials unnecessary.

 

My big complaint about the conference this year was the lack of mobile content in the sessions.  ABA TECHSHOW has a ton of sessions, with multiple tracks occurring simultaneously.  Even a cursory look at the Expo Floor would confirm what you already know — mobile technology is one of the hottest areas of legal technology, as it has been for many years.  And yet there has not been a mobile track at TECHSHOW since 2015.  This makes no sense to me.  There could have easily been a track devoted to just the use of the iPad in the practice of law, or there could have been an even broader track focused on iPads, iPhones, wearable devices, etc.

I raised this issue with co-chair Tom Mighell.  It's not like Tom doesn't get the importance of mobile technology; back in 2011, he authored a book on how lawyers can use iPads, he used to publish a website called iPad 4 Lawyers, and he and I have co-presented at TECHSHOW in the past on mobile technology topics.  Tom understands mobile technology.  Tom's response to me was that mobile technology could just be incorporated as a sub-topic of other sessions.  I agree that is good too, and I saw some of that myself.  For example, in a session focused on using Macs, Florida attorney Katie Floyd, California attorney David Sparks, and New Jersey attorney Victor Medina shared some great tips on using an iPhone and iPad in a law practice:

But there was only a single session which even mentioned mobile technology in its title, a (great) session by technology consultant Brett Burney and California attorney David Sparks called All in the Family:  Seamless Workflows From Mac to iOS:

There are so many more mobile-specific technology topics that could have been explored because so many things work differently (and often better) on an iPad and iPhone than a computer.  Moreover, I know that this is an area that lots of lawyers want to know more about.  I lost count of all of the attorneys who mentioned to me at the conference that the lack of sessions devoted to mobile technology was a curious omission this year.  Indeed, that is also the reason that it makes sense to have a Mac track at TECHSHOW (which was abandoned last year but brought back this year) — many attorneys use Macs, and things are different on a Mac.  I hope that the planners of TECHSHOW 2019 decide to "think different" on this topic, and either restore a full track focused on mobile technology, or have many more session topics throughout the conference with a specific iPad and/or iPhone focus.

The Expo Floor was particularly good this year, with lots of vendors showing off lots of great technology, including iPhone and iPad hardware and software, from the largest companies like Thomson Reuters to small startups.  I enjoyed learning about lots of products that could be useful for my own law firm, and I had a chance to learn about future directions for products that I already use.  Here is a short, two minute video that New Orleans attorney Ernie Svenson created which gives you a sense of all of the activity on the Expo Floor:

Adam Camras, Laurence Colletti and others from the Legal Talk Network were recording podcasts from the Expo Floor, which was fun to see.  Here is a picture from one session being recorded with the TECHSHOW co-Chairs Debbie Foster and Tom Mighell, along with St. Louis attorney Dennis Kennedy and Steve Best of Affinity Consulting:

Lit Software is probably the best publisher of iPad software for attorneys, and they had lots to share at TECHSHOW this year.  Not only did they preview some new features on apps like TrialPad and TranscriptPad, they also pre-announced an iPad app that lawyers will be able to use to collect all of the key date-based information in a case and create a timeline.  I really look forward to trying that one out when it is released later this year.  And I know that they have other useful apps in the lab for a future release.  Here is a picture of Ian O'Flaherty (founder of Lit Software), Tara Cheever (product manager) and Kyle Kvech (lead applications developer) at the booth.  You can tell that I took this picture first thing in the morning because most of the day this booth was packed:

I also enjoyed talking to John Kuntz, co-founder of Bellefield.  That company created iTimeKeep, an app that you can use to enter your time using an iPhone (or iPad) and which integrates with the time entry system that your firm is already using.  (My review.)  I cannot think of how many times I have communicated with a client on my iPhone, or some some other billable work away from my office.  In the past, I would sometimes forget to record that time, but with iTimeKeep on my iPad I can take just a few seconds and record it immediately.

It is always fun to walk around TECHSHOW and bump into people who you "know" from the Internet.  For example, I ran into lots of attorneys who have emailed me iPhone and iPad-related topics of interest over the years, and it was great to talk to them in person.  I also bumped into perhaps the most prolific person on Twitter when it comes to sharing links to legal technology articles (not to mention a frequent author herself) —  New York attorney Nicole Black, who now works for Mycase (@nikiblack on Twitter):

I can't attend TECHSHOW every year, and I missed last year.  But whenever I can attend, I'm always glad that I did.

Categories: iPhone Web Sites

In the news

iPhone J.D. - Sat, 03/10/2018 - 00:27

I just returned from ABA TECHSHOW in Chicago, and it was great to catch up with lots of iPhone J.D. readers while I was there.  I was disappointed by the content of the conference this year because there were so few sessions devoted to mobile devices like the iPhone and iPad, but that was offset somewhat by lots of folks sharing tips on using their iOS devices, and the Expo floor featured lots of companies showing off iOS apps.  I'll have more to say on that next week.  And now, the news of note from the past week:

Categories: iPhone Web Sites

wiki dev test

Lotus Notes wiki recently added info - Wed, 03/07/2018 - 16:01
Categories: Technology

IBM PowerAI: Deep Learning Unleashed on IBM Power Systems Servers

IBM Redbooks Site - Wed, 03/07/2018 - 08:30
Redbook, published: Wed, 7 Mar 2018

This IBM® Redbooks® publication is a guide about the IBM PowerAI Deep Learning solution.

Categories: Technology

We Write CSS Like We Did in the 90s, and Yes, It’s Silly

A list Apart development site - Tue, 03/06/2018 - 08:47

As web developers, we marvel at technology. We enjoy the many tools that help with our work: multipurpose editors, frameworks, libraries, polyfills and shims, content management systems, preprocessors, build and deployment tools, development consoles, production monitors—the list goes on.

Our delight in these tools is so strong that no one questions whether a small website actually requires any of them. Tool obesity is the new WYSIWYG—the web developers who can’t do without their frameworks and preprocessors are no better than our peers from the 1990s who couldn’t do without FrontPage or Dreamweaver. It is true that these tools have improved our lives as developers in many ways. At the same time, they have perhaps also prevented us from improving our basic skills.

I want to talk about one of those skills: the craft of writing CSS. Not of using CSS preprocessors or postprocessors, but of writing CSS itself. Why? Because CSS is second in importance only to HTML in web development, and because no one needs processors to build a site or app.

Most of all, I want to talk about this because when it comes to writing CSS, it often seems that we have learned nothing since the 1990s. We still write CSS the natural way, with no advances in sorting declarations or selectors and no improvements in writing DRY CSS.

Instead, many developers argue fiercely about each of these topics. Others simply dig in their heels and refuse to change. And a third cohort protests even the discussion of these topics.

I don’t care that developers do this. But I do care about our craft. And I care that we, as a profession, are ignoring simple ways to improve our work.

Let’s talk about this more after the code break.

Here’s unsorted, unoptimized CSS from Amazon in 2003.

.serif { font-family: times, serif; font-size: small; } .sans { font-family: verdana, arial, helvetica, sans-serif; font-size: small; } .small { font-family: verdana, arial, helvetica, sans-serif; font-size: x-small; } .h1 { font-family: verdana, arial, helvetica, sans-serif; color: #CC6600; font-size: small; } .h3color { font-family: verdana, arial, helvetica, sans-serif; color: #CC6600; font-size: x-small; } .tiny { font-family: verdana, arial, helvetica, sans-serif; font-size: xx-small; } .listprice { font-family: arial, verdana, sans-serif; text-decoration: line-through; font-size: x-small; } .price { font-family: verdana, arial, helvetica, sans-serif; color: #990000; font-size: x-small; } .attention { background-color: #FFFFD5; }

And here’s CSS from contemporary Amazon:

.a-box { display: block; border-radius: 4px; border: 1px #ddd solid; background-color: #fff; } .a-box .a-box-inner { border-radius: 4px; position: relative; padding: 14px 18px; } .a-box-thumbnail { display: inline-block; } .a-box-thumbnail .a-box-inner { padding: 0 !important; } .a-box-thumbnail .a-box-inner img { border-radius: 4px; } .a-box-title { overflow: hidden; } .a-box-title .a-box-inner { overflow: hidden; padding: 12px 18px 11px; background: #f0f0f0; }

Just as in 2003, the CSS is unsorted and unoptimized. Did we learn anything over the past 15 years? Is this really the best CSS we can write?

Let’s look at three areas where I believe we can easily improve the way we do our work: declaration sorting, selector sorting, and declaration repetition.

Declaration sorting

The 90s web developer, if he or she wrote CSS, wrote CSS as it occurred to them. Without sense or order—with no direction whatsoever. The same was true of last decade’s developer. The same is true of today’s developer, whether novice or expert.

.foo { font: arial, sans-serif; background: #abc; margin: 1em; text-align: center; letter-spacing: 1px; -x-yaddayadda: yes; }

The only difference between now and then: today’s expert developer uses eight variables, because “that’s how you do it” (even with one-pagers) and because at some point in their life they may need them. In twenty-something years of web development we have somehow not managed to make our CSS consistent and easier to work on by establishing the (or even a) common sense standard to sort declarations.

(If this sounds harsh, it’s because it’s true. Developers condemn selectors, shorthands, !important, and other useful aspects of CSS rather than concede that they don’t even know how to sort their declarations.)

In reality, the issue is dead simple: Declarations should be sorted alphabetically. Period.

Why?

For one, sorting makes collaborating easier.

Untrained developers can do it. Non-English speakers (such as this author) can do it. I wouldn’t be surprised to learn that even houseplants can do it.

For another reason, alphabetical sorting can be automated. What’s that? Yes, one can use or write little scripts (such as CSS Declaration Sorter) to sort declarations.

Given the ease of sorting, and its benefits, the current state of affairs borders on the ridiculous, making it tempting to ignore our peers who don’t sort declarations, and to ban from our lives those who argue that it’s easier—or even logical—not to sort alphabetically but instead to sort based on 1) box dimensions, 2) colors, 3) grid- or flexbox-iness, 4) mood, 5) what they ate for breakfast, or some equally random basis.

With this issue settled (if somewhat provocatively), on to our second problem from the 90s.

Selector sorting

The situation concerning selectors is quite similar. Almost since 1994, developers have written selectors and rules as they occurred to them. Perhaps they’ve moved them around (“Oh, that belongs with the nav”). Perhaps they’ve refactored their style sheets (“Oh, strange that site styles appear amidst notification styles”). But standardizing the order—no.

Let’s take a step back and assume that order does matter, not just for aesthetics as one might think, but for collaboration. As an example, think of the letters below as selectors. Which list would be easiest to work with?

c, b · a · a, b · c, d · d, c, a · e · a c · b · a, b · a · c, d · a, c, d · a · e a, b · a, c, d · a · b, c · c, d · e

The fact that one selector (a) was a duplicate that only got discovered and merged in the last row perhaps gives away my preference. But then, if you wanted to add d, e to the list, wouldn’t the order of the third row make placing the new selector easier than placing it in either of the first two rows?

This example gets at the two issues caused by not sorting selectors:

  • No one knows where to add new selectors, creating a black hole in the workflow.
  • There’s a higher chance of both selector repetition and duplication of rules with the same selectors.

Both problems get compounded in larger projects and larger teams. Both problems have haunted us since the 90s. Both problems get fixed by standardizing—through coding guidelines—how selectors should be ordered.

The answer in this case is not as trivial as sorting alphabetically (although we could play with the idea—the cognitive ease of alphabetical selector sorting may make it worth trying). But we can take a path similar to how the HTML spec roughly groups elements, so that we first define sections, and then grouping elements, text elements, etc. (That’s also the approach of at least one draft, the author’s.)

The point is that ideal selector sorting doesn’t just occur naturally and automatically. We can benefit from putting more thought into this problem.

Declaration repetition

Our third hangover from the 90s is that there is and has always been an insane amount of repetition in our style sheets. According to one analysis of more than 200 websites, a median of 66% of all declarations are redundant, and the repetition rate goes as high as 92%—meaning that, in this study at least, the typical website uses each declaration at least three times and some up to ten times.

As shown by a list of some sample sites I compiled, declaration repetition has indeed been bad from the start and has even increased slightly over the years.

Yes, there are reasons for repetition: notably for different target media (we may repeat ourselves for screen, print, or different viewport sizes) and, occasionally, for the cascade. That is why a repetition rate of 10–20% seems to be acceptable. But the degree of repetition we observe right now is not acceptable—it’s an unoptimized mess that goes mostly unnoticed.

What’s the solution here? One possibility is to use declarations just once. We’ve seen with a sample optimization of Yandex’s large-scale site that this can lead to slightly more unwieldy style sheets, but we also know that in many other cases it does make them smaller and more compact.

This approach of using declarations just once has at least three benefits:

  • It reduces repetition to a more acceptable amount.
  • It reduces the pseudo need for variables.
  • Excluding outliers like Yandex, it reduces file size and payload (10–20% according to my own experience—we looked at the effects years ago at Google).

No matter what practice we as a field come up with—whether to use declarations just once or follow a different path—the current level of “natural repetition” we face on sample websites is too high. We shouldn’t need to remind ourselves not to repeat ourselves if we repeat code up to nine times, and it’s getting outright pathetic—again excuse the strong language—if then we’re also the ones to scream for constants and variables and other features only because we’ve never stopped to question this 90s-style coding.

The unnatural, more modern way of writing CSS

Targeting these three areas would help us move to a more modern way of writing style sheets, one that has a straightforward but powerful way to sort declarations, includes a plan for ordering selectors, and minimizes declaration repetition.

In this article, we’ve outlined some options for us to adhere to this more modern way:

  • Sort declarations alphabetically.
  • Use an existing order system or standardize and follow a new selector order system.
  • Try to use declarations just once.
  • Get assistance through tools.

And yet there’s still great potential to improve in all of these areas. The potential, then, is what we should close with. While I’ve emphasized our “no changes since the 90s” way of writing CSS, and stressed the need for robust practices, we need more proposals, studies, and conversations around what practices are most beneficial. Beneficial in terms of writing better, more consistent CSS, but also in terms of balancing our sense of craft (our mastery of our profession) with a high degree of efficiency (automating when it’s appropriate). Striving to achieve this balance will help ensure that developers twenty years from now won’t have to write rants about hangovers from the 2010s.

Categories: Technology

Pages

Subscribe to www.hdgonline.net aggregator