Feed aggregator

Db2 Skeleton Cloning: Protecting Your Production Environment

IBM Redbooks Site - Fri, 11/17/2017 - 08:30
Redpaper, published: Fri, 17 Nov 2017

IBM Db2® for z/OS® is well known as the gold-standard information steward.

Categories: Technology

IBM Open Platform for Database as a Service Implementation and Best Practices Guide For Linux on IBM Power Systems

IBM Redbooks Site - Fri, 11/17/2017 - 08:30
Draft Redbook, last updated: Fri, 17 Nov 2017

This IBM Redbooks publication describes how to implement an Open Platform for Database as a Service (DBaaS) on IBM Power Systems environment for Linux, and demonstrate the open source tools, optimization and best practices guidelines for it.

Categories: Technology

In the news

iPhone J.D. - Fri, 11/17/2017 - 01:37

California attorney David Sparks discusses getting work done with an iPad instead of a computer, noting that Microsoft Word on the iPad is really just one feature short of giving attorneys all that they need to give up using the computer for word processing:  proper support for Styles.  I agree 100%, and every time Microsoft updates its iOS app, this is the first thing I look for in the list of what is new.  And now, the news of note from the past week:

  • On the latest edition of Brett Burney's Apps in Law podcast, Kentucky attorney Jeff Alford discusses using TextExpander on the iPhone and iPad.
  • Security expert Rich Mogull wrote a fascinating article in TidBITS explaining why Face ID on the iPhone X is a major step forward in mobile device security.
  • Tim Bradshaw of Financial Times discusses iPhone security, including how Face ID improves security.
  • If you ever find that Face ID doesn't work, Yoni Heisler of BGR explains that rather than try again, you should enter your passcode.  That way, the iPhone X will learn to adjust and will do a better job in the future recognizing your face.
  • Jared Newman of TechHive reivews the Apple TV 4K.
  • The iPhone 8 and iPhone X support fast charging, much like the iPad Pro.  I previously reviewed the combination of Apple’s 29W USB-C Power Adapter and USB-C to Lightning Cable, a great pair for getting the fastest possible charging.  But it costs $75.  Joanna Stern of the Wall Street Journal ran some tests and concluded that while Apple's USB-C combo is the fastest, using a $20 Apple 12W charger (which comes with the iPad) or using an $11 Anker 24W charger is almost as fast for the iPhone 8 / iPhone X.  I still like having Apple's USB-C combo because I have an iPad Pro which takes much better advantage of USB-C, but if you are only looking for fast charging on an iPad, it looks like Apple's USB-C combo is overkill.
  • According to Neil Hughes of AppleInsider, you can save a tremendous amount of battery life on the iPhone X by using mostly dark screens, because black on an OLED display uses substantially less power.  I recently switched to an all-black backgrounds for the home screen on my iPhone X, not to save power,  but instead because I love the contrast on that OLED screen between a true black and the icon colors.
  • I didn't expect to see an iPhone X review on Android Central, but the editor of that site, Daniel Bader, wrote an interesting review of the iPhone X from the perspective of an Android fan.
  • Mark Prigg of the Daily Mail reports that a kitesurfer off the coast of California found himself stranded in shark-infested waters and used the cellular function of his Apple Watch 3 to call for help.
  • CarPlay Life offers some good advice for using Siri with Apple CarPlay.  One tip I learned from that article is that asking Siri for directions to X will just show you the directions on the screen, but asking Siri to take me to X will not only find the directions but also start providing directions advice, saving you the step of tapping the "Go" button on the CarPlay screen.
  • Roger Fingas of AppleInsider reviews the August Smart Lock Pro + Connect bundle, a Home Kit-compatible smart lock.
  • And finally, here is the cute video released by Apple this week showing a teenager using an iPad Pro for so many things that she forgets what a computer is; this is the video referenced in David Spark's post that I linked to above:

Categories: iPhone Web Sites

Feedback That Gives Focus

A list Apart development site - Tue, 11/14/2017 - 10:00

I have harbored a lifelong dislike of feedback. I didn’t like it in sixth grade when a kid on the bus told me my brand new sneakers were “too bright.” And I didn’t like it when a senior executive heard my pitch for a digital project and said, “I hate this idea.” Turns out my sneakers were pretty bright, and my pitch wasn’t the best idea. Still, those experiences and many others like them didn’t help me learn to stop worrying and love the feedback process.

We can’t avoid feedback. Processing ideas and synthesizing feedback is a big part of what we do for a living. I have had plenty of opportunities to consider why both giving and receiving feedback is often so emotionally charged, so challenging to get right.

And here’s what I’ve found to be true.

When a project is preoccupying us at work, we often don’t think about it as something external and abstract. We think about it more like a story, with ourselves in the middle as the protagonist—the hero. That might seem melodramatic, especially if your work isn’t the kind of thing they’d make an inspirational movie about. But there’s research to back this up: humans use stories to make sense of the world and our place within it.

Our work is no different. We create a story in our heads about how far we’ve come on a project and about where we’re going. This makes discussing feedback dangerous. It’s the place where someone else swoops in and hijacks your story.

Speaking personally, I notice that when I’m giving feedback (and feeling frustrated), the story in my head goes like this: These people don’t get it. How can I force them into thinking the same way I do so that we can fix everything that’s wrong with this project, and in the end, I don’t feel like a failure?

Likewise, when I’m receiving feedback (and feeling defensive), the story goes like this: These people don’t get it. How can I defend our work so that we keep everything that I like about this project, and in the end, I don’t feel like a failure?

Both of these postures are ultimately counterproductive because they are focused inward. They’re really about avoiding shame. Both the person giving and receiving feedback are on opposing sides of the equation, protecting their turf.

But like a good story, good feedback can take us out of ourselves, allowing us to see the work more clearly. It can remove the artificial barrier between feedback giver and receiver, refocusing both on shared goals.

Change your habits around feedback, and you can change the story of your project.

Here are three ways to think about feedback that might help you do just that.

Good feedback helps us understand how we got here

Here’s a story for you. I was presenting some new wireframes for an app to the creative leads on the project. There were a number of stakeholders and advisors on the project, and I had integrated several rounds of their feedback into the harmonious and brilliant vision that I was presenting in this meeting. That’s the way I hoped the story would go, anyway.

But at the end of the meeting, I got some of the best, worst feedback I have ever received: “We’ve gotten into our heads a little bit with this concept. Maybe it should be simpler. Maybe something more like this …” And they handed me a loose sketch on paper to illustrate a new, simpler approach. I had come for sign-off but left with a do-over.

I felt ashamed. How could I have missed that? Even though that feedback was hard to hear, I walked away able to make important changes, which led to a better outcome in the end. Here are the reasons why:

First, the feedback started as a conversation. Conversations (rather than written notes) make it easier to verify assumptions. When you talk face-to-face you can ask open-ended questions and clarify intent, so you don’t jump to conclusions. Talking helps you find where the trouble is much faster.

The feedback connected the dots between problems in our process so far (trying to reconcile too many competing ideas) and how it led to the current result (an overly complicated product). The person who gave the feedback helped me see how we got to where we were, without assigning blame or shaming me in the process.

The feedback was direct. They didn’t try to mask the fact that the concept wasn’t working. Veiled or vague criticism does more harm than good; the same negativity comes through but without a clear sense of what to do next.

Good feedback invites each person to contribute their best work No thought, no idea, can possibly be conveyed as an idea from one person to another. … Only by wrestling with the conditions of the problem … first hand … does he think. John Dewey, Democracy and Education

Here’s another story. I was the producer on an app-based game, and the team was working on a part of the user interface that the player would use again and again. I was convinced that the current design didn’t “feel” right. I kept pushing for a change, against the input of others, and I gave the team some specific feedback about what I wanted to see done. The designers played along and tried it out. But it became clear that my feedback wasn’t helping, and the design director (gently) stepped in and steered us out of my design tangent and back on course.

John Dewey had it right in that quote above; you can’t think for someone else. And that’s exactly what I was doing: giving specific solutions without inviting the team to engage with the problem. And the results were worse for it.

It’s very tempting to use feedback to cajole and control people into doing things your way. But that usually leads to mediocre results. You have a team for a reason: you can’t possibly do everything on your own. Instead, when giving feedback try to remember that you’re building a team of individual contributors that will work together to make a better end product.

Here are a few feedback habits that help avoid the trap of using feedback to control, and instead, bring out the best in people.

Don’t give feedback until the timing is right

Feedback isn’t useful if it’s given before the work is really ready to be looked at. It’s also not useful to give feedback if you have not taken the time to look at the work and think about it in advance. If you rush either of these, the feedback will devolve into a debate about what could have been, rather than what’s actually there now. That invites confusion, defensiveness, and inefficiency.

Be just specific enough

Good feedback should have enough specifics to clearly identify the problem. But, usually, it’s better to not give a specific solution. The feedback in this example goes too far:

The background behind the menu items is a light blue on a darker blue. This makes it hard to see some options. Change the background fill to white and add a thin, red border around each square. When an option is selected, perhaps the inside border should glow red but not fill in all the way.

Instead, feedback that clearly identifies the problem is probably enough:

The background behind the menu items makes it a little hard for me to see some options. Any way we might make it easier to read?

Give the person whose job it is to solve the problem the room to do just that.  They might solve it in a better way that you hadn’t anticipated.

Admit when you’re wrong

When you acknowledge a mistake openly and without fear, it gives permission for others on the team to do the same. This refocuses energies away from ego-protection and toward problem solving. I chose to admit I got it wrong on that app project I mentioned above; the designers had it right and I told them I was glad they stuck to their guns. Saying that out loud was actually easier than I thought, and our working relationship was better for it.

Good feedback tells a story about the future In my writing, as much as I could, I tried to find the good, and praise it. Alex Haley

We’ve said that good feedback connects past assumptions and decisions to current results, without assigning blame. Good feedback also identifies issues in a timely and specific way, giving people room to find novel solutions and contribute their best work.

Lastly, I’ve found that most useful feedback helps us look beyond the present state of our work and builds a shared vision of where we’re headed.

One of maybe the most overlooked tools for building that shared vision is actually pretty simple: positive feedback. The best positive feedback acknowledges great work that’s already complete, doing so in a way that is future-focused.  Its purpose is to point out what we want to do more of as we move forward.

In practice, I’ve found that I can become stingy with positive feedback, especially when it’s early in a project and there’s so much work ahead of us. Maybe this is because I’m afraid that mentioning the good things will distract us from what’s still in need of improvement.

But ironically, the opposite is true: it becomes easier to fix what’s broken once you have something (however small) that you know is working well and that you can begin to build that larger vision around.

So be equally direct about what’s working as you are with what isn’t, and you’ll find it becomes easier to rally a team around a shared vision for the future.  The first signs of that future can be found right here in the present.

Like Mr. Haley said: find the good and praise it.

Oh and one more thing: say thank you.

Thank people for their contributions. Let me give that a try right now:

It seemed wise to get some feedback from others when writing about feedback. So thanks to everyone in the PBS KIDS family of producers who generously shared their thoughts and experience with me in preparation of this article. I look forward to hearing your feedback.

Categories: Technology

IBM DS8000 EasyTier (for DS8880 R8.3 or later)

IBM Redbooks Site - Tue, 11/14/2017 - 08:30
Redpaper, published: Tue, 14 Nov 2017

This IBM® Redpaper™ publication describes the concepts and functions of IBM System Storage® Easy Tier® and explains its practical use with the IBM DS8800 series and License Machine Code 8.8.30.xx.xx, or later.

Categories: Technology

Implementing a VersaStack Solution by Cisco and IBM with IBM Storwize V5030, Cisco UCS Mini, VMware 6.5, Hyper-V, and SQL Server

IBM Redbooks Site - Tue, 11/14/2017 - 08:30
Redbook, published: Tue, 14 Nov 2017

VersaStack, an IBM® and Cisco integrated infrastructure solution, combines computing, networking, and storage into a single integrated system.

Categories: Technology

In the news

iPhone J.D. - Fri, 11/10/2017 - 22:17

I've enjoyed my first week with the iPhone X more than I've enjoyed my first week with any other iPhone except perhaps for my first iPhone, the iPhone 3G back in 2008.  I've picked up my iPhone 7 several times this week, and it now seems so dated because they lack the huge screen.  The larger screen on the iPhone X quickly feels like this is the screen that was always supposed to be on an iPhone, and I'm sure that in a few years almost all iPhone users will feel the same way.  The screen in the standout feature, but Face ID runs a close second because it is so incredible to have the iPhone unlock without my having to do anything.  And thanks to the release of the new Clips app (discussed below), we are now starting to see new and interesting things that can be done with all of the front-facing cameras the sit in the notch at the top of the screen.  And now, the news of note from the past week:

  • California attorney David Sparks gave some of his initial thoughts about the iPhone X.
  • South Carolina attorney Justin Kahn explains what he likes about the iPhone X on his iPad Notebook website.
  • Jason Snell of Six Colors discusses the iPhone X after using it for a week.
  • Michael Gartenberg of iMore discusses what makes the iPhone X so special.
  • By default, you need to look at an iPhone X to unlock it.  With earlier iPhones, you can unlock with a fingerprint, even if someone else puts your finger on the device while you are asleep.  That led to some chaos this week when a woman on a Qatar Airways flight put her sleeping husband's finger on his iPhone to unlock it and discovered that he was having an affair.  The woman, who reportedly had been drinking, then became disruptive, and ultimately the flight had to be diverted to get her and her husband off the plane.  Saurabh Sinhai of The Times of India has additional details.
  • Nick Compton of Wallpaper interview's Apple's Jony Ive to discuss Apple's new Apple Park building, and other Apple design issues.  The photography in this article is impressive.
  • Now that we all know what the new iPhone looks like, what will the next iPad look like?  Mark Gurman and Alex Webb of Bloomberg have some ideas, and Jason Snell of Six Color notes that these predictions seem reasonable — stuff like Face ID on an iPad and a new Apple Pencil.
  • Peeking further into the future, Michael Simon of Macworld discusses a possible wearable device by Apple that could be targeted for a 2020 release.  Apple CEO Tim Cook does love to talk about Augmented Reality, and as cool as it is on an iPhone, it does seem like Apple has additional applications in mind for this technology.
  • Apple may be working on a second edition Apple Pencil, but what are the best styluses today?  The GoodNotes Blog selects some favorites, and I agree with this list.  The Apple Pencil is by far the best choice, but if you don't have an iPad Pro there are some other good ones to choose from.
  • John Gruber of Daring Fireball discusses the new Clips app by Apple, which is now at version 2.0.  As Griber notes, it is a major upgrade.  One of the fun new features is to use the iPhone X TrueDepth camera to place yourself on the Millennium Falcon.  I showed off a little by making this short video right after the app was updated, but then Rian Johnson (the director of the upcoming Star Wars movie The Last Jedi) posted this video and immediately put mine to shame.
  • Speaking of the front-facing cameras on the iPhone X, Jason Snell wrote a good article for Tom's Guide explaining how to use Face ID on the iPhone X.
  • The visitor center at Apple Park opens a week from today, November 17, according to Chance Miller of 9to5Mac.  It's nice that Apple will finally have a designated area for the general public to visit the Apple campus.  I've visited Apple's Infinite Loop campus in the past with an Apple employee escorting me, but having that friend on the inside was always critical.  That changes next week.
  • Jessica Smith of Business Insider reports that the attempted merger between T-Mobile and Spring is now called off.
  • Tomorrow, November 11, if you exercise for 11 minutes with your Apple Watch, you'll earn a Veteran's Day badge.  iMore has the details.
  • David Pogue of Yahoo compares the Apple TV, Roku and other streaming boxes.  He says that the Apple TV is the best, but the Roku is a great value because it is less expensive.  If you have lots of other Apple devices, however, I think that the Apple TV makes the most sense.
  • And finally, Joanna Stern of the Wall Street Journal discusses how to use the iPhone X, but does it by taking on the personality of the new Animoji in the Messages app.  The video is amusing and informative:

Categories: iPhone Web Sites

Sharing Box Content in IBM Content Navigator

IBM Redbooks Site - Wed, 11/08/2017 - 08:30
Web Doc, published: Wed, 8 Nov 2017

Collaboration is a popular approach to delivering global solutions.

Categories: Technology

2017 ABA Tech Survey shows all-time high iPhone use by attorneys

iPhone J.D. - Tue, 11/07/2017 - 23:49

New survey results indicate that a record number of attorneys are using an iPhone in their law practice — over 70% of all attorneys in the United States.  These numbers come from the ABA Legal Technology Resource Center, which conducts a survey every year to gauge the use of legal technology by attorneys in private practice in the United States.  The 2017 report (edited by Joshua Poje) was just released, and as always, I was particularly interested in Volume VI, titled Mobile Lawyers.  No survey is perfect, but the ABA tries hard to ensure that its survey has statistical significance, and every year this is one of the best sources of information on how attorneys use technology.  Note that the survey was conducted from February to May of 2017, so these numbers don't reflect any changes in what attorneys are using which occurred within the last six months. This is the eighth year that I have reported on this survey, and with multiple years of data we can see some interesting trends.  (My reports on prior ABA surveys are located here: 2016, 2015, 2014, 2013, 2012, 2011, 2010.)

Over 70% of all U.S. attorneys use an iPhone

The 2017 survey revealed that a record number of attorneys in the U.S. are using a smartphone (around 95%), and of the attorneys using a smartphone, a record number are using an iPhone (around 75%).

The survey asks each attorney "Do you use a smartphone (e.g. BlackBerry, iPhone, Android) for law-related tasks while away from your primary workplace?"  Back in 2010, the number of attorneys answering "no" was around 12%.  It decreased over the years to 10% and then last year to 6.8%.  This year, it is at an all time low of only 4.4%.  I'm somewhat surprised it has taken that long to get here, but we can now say that over 95% of all attorneys use a smartphone.

In 2013, the big news was that, for the first time, over half of all attorneys were using an iPhone.  In 2014 and 2015 the percentage was around 60%.  In 2016, there was a big increase up to 68.4%.  In 2017, the number is up to 74.9%.  Taking into account that 4.4% of all attorneys are not using any smartphone, we can now say that 71.6% of all attorneys in private practice in the U.S. are using an iPhone in their law practice, which is an all-time high.  According to the ABA 2017 National Lawyer Population Survey, there are 1,335,963 attorneys in the U.S., which suggests that there could be over 956,000 attorneys in the U.S. using an iPhone.

If 71.6% of all attorneys are using an iPhone, and 4.4% of attorneys are not using any smartphone, what are the others using?  Most of them are using an Android smartphone, around 21.6%. 

Back in 2011, 40% of all attorneys used a BlackBerry, and I'm sure all of us remember a time when it was incredibly common to see another lawyer with a BlackBerry.  However, BlackBerry use by attorneys has dropped sharply since 2011.  In 2017, the number reached a new low of only 2%. 

Finally, there are 0.6% of attorneys using some sort of Microsoft Windows operating system on their smartphone in 2017, and another 1.3% either report using "other" or say that they don't know what kind of smartphone they are using. 

If you add the numbers, you'll notice that they add up to 101.5%.  But it makes sense for the number to be slightly over 100% because I know that a small number of attorneys use multiple smartphones.

The following pie chart is somewhat imprecise because, as I just noted, the actual numbers add up to just over 100%, but it gives you a general, graphical sense of the relative use:

To place these numbers in historical context, the following chart shows lawyer smartphone use over recent years.  The two dramatic changes in this chart are of course the plunge in BlackBerry use and the surge in iPhone use.  There has been a more gradual, but noticeable, decrease in the number of attorneys not using a smartphone at all.  As for Android use, there was a slight increase from 2011 to 2015, but then a slight decrease in the last two years.  The "Other" category in this chart includes Windows, something else, and those who don't know what smartphone they are using.

Why are attorneys choosing iPhone, Android or BlackBerry?  Firm size might have something to do with it.  Almost all of the attorneys still using a BlackBerry are at the largest law firms.  On the other hand, Android use is highest among solo attorneys.  And for firm sizes between the smallest and largest, it looks like those BlackBerry or Android users become iPhone users:

What are these attorneys doing with their iPhones and other smartphones? Almost all are using them to make phone calls and handle emails.  Around 75% are regularly using smartphones for calendars, contacts, and accessing the Internet.  Other popular uses are text messaging, GPS/maps, taking pictures and mobile-specific research apps.  Only 8.2% use a smartphone to track time and expenses (which is down slightly from 10% last year).

Almost 5% of attorneys report that they are not using any security measures on their smartphone, which is unfortunate; for attorneys, that number really should be zero.  If nothing else, you need to use a password to protect your device.  (And if you use an iPhone, Apple is making even harder to use a device without a passcode.)

50% of survey respondents use Verizon for their smartphone.  AT&T has 37.4%, Sprint has 6.2%, T-Mobile has 4.7%, US Cellular and Cricket Wireless each have 0.6%, and 1.4% said "other" or "don't know."

About 40% of U.S attorneys use an iPad

Apple introduced the original iPad in 2010, and for the first few years it resulted in a surge in lawyer tablet use.  In 2011, only 15% of all attorneys responded that they use a tablet.  That number more than doubled to 33% in 2012, and rose to 48% in 2013.  But since then, the number has essentially held steady:  49% in 2014, 49.6% in 2015, 50.6% in 2016, and 49.8 in 2017%.  Suffice it to say that about half of all U.S. attorneys in private practice currently use a tablet, and that has remained true since 2014.

It used to be that around 90% of attorneys using a tablet were using an iPad.  It was 89% in 2011, 91% in 2012, and 91% in 2013.  From 2014 to 2016, that number stayed around 84%.  In 2017, that number is at an all-time low of 81.3%.  If 81.3% of the 49.8% of attorneys use a tablet use an iPad, that means that about 40.5% of all U.S. attorneys are using an iPad in 2017.

Keep in mind, though, that this data was all collected in early 2017.  As I reported yesterday, iPad sales peaked in 2014 and then decreased substantially, but for the last six months, iPad sales have started to increase again, perhaps due to the new 10.5" iPad Pro and the second generation 12.9" iPad Pro released in mid-2017.  Assuming that lawyers were a part of this recent turn-around in iPad sales, my guess is that the iPad numbers will increase in the 2018 survey.  We'll see.

As for the lawyers using a tablet but not using an iPad, in 2017 11.1% use a Microsoft Windows operating system (a jump from 6.6% in 2016, presumably thanks to the Windows Surface devices), 9.9% use Android (versus 10.1% in 2016), and 1.6% use something else or don't know what they use.  My guess is that some portion of the increase in Windows tablet users were previously iPad users.

Looking at the past seven years on a chart shows visually how the percentage of attorneys using a tablet increased substantially from 2011 to 2013, and then has remained around 50%.  For the half of U.S. attorneys using an iPad, the vast majority use an iPad.  For the other half of U.S. attorneys who were not interested in a tablet device in 2013, apparently they haven't changed their minds yet.

What are these attorneys doing with their iPads and other tablets?  Pretty much the same thing that they are doing with their smartphones (other than the phone function), with over half of attorneys reporting that they are regularly using their tablets for internet access, email and calendars.

Popular apps

The survey also asked attorneys to identify apps that they use.  I want to start by making the same objection that I made for the last two years:  I don't like how the ABA asks the question.  The ABA first asks "Have you ever downloaded a legal-specific app for your smartphone?"  In 2017, 41.8% said yes.  When I see the word "smartphone" in this question, I think of my iPhone, not my iPad.  Then the next question asks:  "What legal specific app(s) did you download?"  When I read the questions in that order, I'm thinking of the apps that I downloaded on my iPhone, not my iPad.  But others must be reading the question differently because I see TrialPad and TranscriptPad in the answers, and those apps exist only on the iPad, not on the iPhone.  I would have never mentioned those apps when answering the question, even though I use them on my iPad.

So while I question how much value you can put in these answers, for what it is worth, the top 13 apps listed are, in order of the percentage of attorneys mentioning them:

  1. Westlaw
  2. Fastcase
  3. Lexis Advance
  4. A legal dictionary app
  5. TrialPad
  6. TranscriptPad
  7. Courtlink
  8. LexisNexis Get Cases & Shepardize
  9. Clio
  10. ABA apps
  11. LexisNexis Legal News
  12. HeinOnline
  13. Westlaw News

The ABA then asked about general business apps, and the questions have the same ambiguity:  the ABA first asked if the attorney ever downloaded a general business app to a smartphone (47.1% said yes in 2017), and then the ABA asked which apps were downloaded, without making it clear whether the question was asking about the iPhone and iPad.  The answers provided were, in this order:

  1. Dropbox
  2. LinkedIn
  3. Evernote
  4. GoodReader
  5. LogMeIn
  6. Documents to Go
  7. Box
  8. QuickOffice
  9. MS Office/Word
  10. Notability

It amazes me that Microsoft Word is so low on this list (only 6.4% report using it), but at least it made the list in 2017; in prior years, it wasn't even on the list.  Word is one of the most useful general-purpose apps that any lawyer can have on his iPhone, iPad, Android or Windows mobile device.  If you are not using it yet on your iPhone and iPad, you are missing out on an app that is incredibly useful in a law practice.

Categories: iPhone Web Sites

Ten Extras for Great API Documentation

A list Apart development site - Tue, 11/07/2017 - 10:00

If you manage to create amazing API documentation and ensure that developers have a positive experience implementing your API, they will sing the praises of your product. Continuously improving your API documentation is an investment, but it can have a huge impact. Great documentation builds trust, differentiates you from your competition, and provides marketing value.

I’ve shared some best practices for creating good API documentation in my article “The Ten Essentials for Good API Documentation.” In this article, I delve into some research studies and show how you can both improve and fine-tune different aspects of your API documentation. Some of these extras, like readability, are closer to essentials, while others are more of a nice-to-have, like personality. I hope they give you some ideas for building the best possible docs for your product.

Overview page

Whoever visits your API documentation needs to be able to decide at first glance whether it is worth exploring further. You should clearly show:

  • what your API offers (i.e., what your products do);
  • how it works;
  • how it integrates;
  • and how it scales (i.e., usage limits, pricing, support, and SLAs).
Spotify’s API documentation clearly states what the API does and how it works, and it provides links to guides and API references organized in categories.

An overview page targets all visitors, but it is especially helpful for decision-makers. They have to see the business value: explain to them directly why a company would want to use your API.

Developers, on the other hand, want to understand the purpose of the API and its feature set, so they tend to turn to the overview page for conceptual information. Show them the architecture of your API and the structure of your docs. Include an overview of different components and an introduction into the request-response behavior (i.e., how to integrate, how to send requests, and how to process responses). Provide information on the platforms on which the API is running (e.g., Java) and possible interactions with other platforms.

As the study “The role of conceptual knowledge in API usability” found, without conceptual knowledge, developers struggle to formulate effective queries and to evaluate the relevance or meaning of content they find. That’s why API documentation should not only include detailed examples of API use, but also thorough introductions to the concepts, standards, and ideas in an API’s data structures and functionality. The overview page can be an important component to fulfill this role.

Braintree’s API overview page provides a clear overview of their SDKs, along with a visual step-by-step explanation of how their API works. Examples

For some developers, examples play a more important role in getting started with an API than the explanations of calls and parameters.

A recent study, “Application Programming Interface Documentation—What Do Software Developers Want?,” explored how software developers interact with API documentation: what their goals are, how they learn, where they look for information, and how they judge the quality of API docs.

The role of examples

The study found that after conducting an initial overview of what the API does and how it works, developers approach learning about the API in two distinct ways: some follow a top-down approach, where they try to build a thorough understanding of the API before starting to implement specific use cases, while others prefer to follow a bottom-up approach, where they start coding right away.

This latter group has a code-oriented learning strategy; they start learning by trying and extending code examples. Getting into an API is most often connected with a specific task. They look for an example that has the potential of serving as a basis to solve their problem, but once they’ve found the solution they were looking for, they usually stop learning.

Examples are essential for code-oriented learners, but all developers benefit from them. The study showed that developers often trust examples more than documentation, because if they work, they can’t be outdated or wrong. Developers often struggle with finding out where to start and how to begin with a new API—examples can become good entry points in this case. Many developers can grasp information more easily from code than text, and they can re-use code in examples for their own implementation. Examples also play other roles that are far from obvious: they automatically convey information about dependencies and prerequisites, they help identify relevant sections in the documentation when developers are scanning the page, and they intuitively show developers how code that uses the API should look.

Improve your examples

Because examples are such a crucial component in API documentation, better examples mean better docs.

To ensure the quality of your examples, they should be complete, be programmed professionally, and work correctly. Because examples convey so much more than the actual use case, make sure to follow the style guidelines of the respective community and show best-practice approaches. Add brief, informative explanations; although examples can be self-explanatory, comments included with sample code help comprehension.

Add concrete, real-life examples whenever you can. If you don’t have real examples, make sure they at least look real: use realistic variable names and functions instead of abstract ones.

When including examples, you have a variety of formats and approaches to choose from: auto-generated examples, sample applications, client libraries, and examples in multiple languages.

Auto-generated examples

Autodoc tools like Swagger Codegen and API Blueprint automatically generate documentation from your source code and keep it up-to-date as the code changes. Use them to generate reference libraries and sample code snippets, but be aware that what you produce this way is only skeleton—not fleshed out—documentation. You will still have to add explanations, conceptual information, quick-start guides, and tutorials, and you should still pay attention to other aspects like UX and good-quality copy.

On the Readme blog, they explore autodoc tools and their limitations in more depth through a couple of real-world examples.

Sample applications

Working applications that use the API are a great way to show how everything works together and how the API integrates with different platforms and technologies. They are different than sample code snippets, because they are stand-alone solutions that show the big picture. As such, they are helpful to developers who would like to see how a full implementation works and to have an overall understanding of how everything in the API ties together. On the other hand, they are real products that showcase the services and quality of your API to decision makers. Apple’s iOS Developer Portal offers buildable, executable source examples of how to accomplish a task using a particular technology in a wide variety of categories.   

Client libraries

Client libraries are chunks of code that developers can add to their own development projects. They are usually available in various programming languages, and cover basic functionality for an application to be able to interact with the API. Providing them is an extra feature that requires ongoing investment from the API provider, but doing so helps developers jump-start their use of the API. GitHub follows the practical approach of offering client libraries for the languages that are used the most with their API, while linking to unsupported, community-built libraries written in other, less popular languages.

Examples in multiple languages

APIs are platform- and language-independent by nature. Developers can use an API’s services with the language of their choice, but this means good documentation should cover at least the most popular languages used with that particular API (e.g., C#, Java, JavaScript, Go, Objective-C, PHP, Python, Ruby, and Swift). Not only should you provide sample code and sample applications in different languages, but also these samples should reflect the best-practice approach for each language.


API documentation is a tool that helps developers and other stakeholders do their job. You should adapt it to the way people use it, and make it as easy to use as possible. Consider the following factors:

  • Copy and paste: Developers copy and paste code examples to use them as a starting point for their own implementation. Make this process easier with either a copy button next to relevant sections or by making sections easy to highlight and copy.
  • Sticky navigation: When implemented well, fixing the table of contents and other navigation to the page view can prevent users from getting lost and having to scroll back up.
  • Clicking: Minimize clicking by keeping related topics close to each other.
  • Language selector: Developers should be able to see examples in the language of their choice. Put a language selector above the code examples section, and make sure the page remembers what language the user has selected.
  • URLs: Single page views can result in very long pages, so make sure people can link to certain sections of the page. If, however, a single page view doesn’t work for your docs, don’t sweat it: just break different sections into separate pages. .main-content figure figcaption { display: block;margin: 12px 0;text-align: center;font-size: 14px;line-height: 24px;font-style: italic;font-family: georgia,serif; } .main-content figure { margin-top: 36px;margin-bottom: 36px;overflow: hidden; } Great usability: Stripe’s API documentation changes the URL dynamically as you scroll through the page.

    Another best practice from Stripe: the language selector also changes the URL, so URLs link to the right location in the right language.

  • Collaboration: Consider allowing users to contribute to your docs. If you see your users edit your documentation, it indicates there might be room for improvement—in those parts of your docs or even in your code. Additionally, your users will see that issues are addressed and the documentation is frequently updated. One way to facilitate collaboration is to host your documentation on GitHub, but be aware that this will limit your options of interactivity, as GitHub hosts static files.


Providing an option for users to interact with your API through the documentation will greatly improve the developer experience and speed up learning.

First, provide a working test API key or, even better, let your users log in to your documentation site and insert their own API key into sample commands and code. This way they can copy, paste, and run the code right away.

As a next step, allow your users to make API calls directly from the site itself. For example, let them query a sample database, modify their queries, and see the results of these changes.

A more sophisticated way to make your documentation more interactive is by providing a sandbox—a controlled environment where users can test calls and functions against known resources, manipulating data in real-time. Developers learn through the experience of interacting with your API in the sandbox, rather than by switching between reading your docs and trying out code examples themselves. Nordic APIs explains the advantages of sandboxing, discusses the role of documentation in a sandboxed environment, and shows a possible implementation. To see a sandbox in action, try out the one on Dwolla’s developer site.


The study exploring how software developers interact with API documentation also explored how developers look for help. In a natural work environment, they usually turn to their colleagues first. Then, however, many of them tend to search the web for answers instead of consulting the official product documentation. This means you should ensure your API documentation is optimized for search engines and will turn up relevant results in search queries.

To make sure you have the necessary content available for self-support, include FAQs and a well-organized knowledge base. For quick help and human interaction, provide a contact form, and—if you have the capacity—a help-desk solution right from your docs, e.g., a live chat with support staff.

The study also pointed at the significant role Stack Overflow plays: most developers interviewed mentioned the site as a reliable source of self-help. You can also support your developers’ self-help efforts and sense of community by adding your own developer forum to your developer portal or by providing an IRC or Slack channel.


As with all software, APIs change and are regularly updated with new features, bug fixes, and performance improvements.

When a new version of your API comes out, you have to inform the developers working with your API about the changes so they can react to them accordingly. A changelog, also called release notes, includes information about current and previous versions, usually ordered by date and version number, along with associated changes.

If there are changes in a new version that can break old use of an API, put warnings on top of relevant changelogs, even on top of your release notes page. You can also bring attention to these changes by highlighting or marking them permanently.

To keep developers in the loop, offer an RSS feed or newsletter subscription where they can be notified of updates to your API.

Besides the practical aspect, a changelog also serves as a trust signal that the API and its documentation are actively maintained, and that the information included is up-to-date.

Analytics and feedback

You can do some research by getting to know your current and potential clients, talking to people at conferences, exploring your competition, and even conducting surveys. Still, you will have to go with a lot of assumptions when you first build your API docs.

When your docs are up, however, you can start collecting usage data and feedback to learn how you can improve them.

Find out about the most popular use cases through analytics. See which endpoints are used the most and make sure to prioritize them when working on your documentation. Get ideas for tutorials, and see which use cases you haven’t covered yet with a step-by-step walkthrough from developer community sites like Stack Overflow or your own developer forums. If a question regarding your API pops up on these channels and you see people actively discussing the topic, you should check if it’s something that you need to explain in your documentation.

Collect information from your support team. Why do your users contact them? Are there recurring questions that they can’t find answers for in the docs? Improve your documentation based on feedback from your support team and see if you have been successful: have users stopped asking the questions you answered?

Listen to feedback and evaluate how you could improve your docs based on them. Feedback can come through many different channels: workshops, trainings, blog posts and comments about your API, conferences, interviews with clients, or usability studies.


Readability is a measure of how easily a reader can understand a written text—it includes visual factors like the look of fonts, colors, and contrast, and contextual factors like the length of sentences, wording, and jargon. People consult documentation to learn something new or to solve a problem. Don’t make the process harder for them with text that is difficult to understand.

While generally you should aim for clarity and brevity from the get-go, there are some specific aspects you can work on to improve the readability of your API docs.

Audience: Expect that not all of your users will be developers and that even developers will have vastly different skills and background knowledge about your API and business domain. To cater to the different needs of different groups in your target audience, explain everything in detail, but provide ways for people already familiar with the functionality to quickly find what they are looking for, e.g., add a logically organized quick reference.

Wording: Explain everything as simply as you can. Use short sentences, and make sure to be consistent with labels, menu names, and other textual content. Include a clear, straightforward explanation for each call. Avoid jargon if possible, and if not, link to domain-related definitions the first time you use them. This way you can make sure that people unfamiliar with your business domain get the help they need to understand your API.

Fonts: Both the font size and the font type influence readability. Have short section titles and use title case to make it easier to scan them. For longer text, use sans serif fonts. In print, serif fonts make reading easier, but online, serif characters can blur together. Opt for fonts like Arial, Helvetica, Trebuchet, Lucida Sans, or Verdana, which was designed specifically for the web. Contrast plays an important role as well: the higher the contrast, the easier the text is to read. Consider using a slightly larger font size and different typeface for code than for text to help your users’ visual orientation when switching back and forth between their code editor and your documentation.

Structure: API documentation should cater to newcomers and returning visitors alike (e.g., developers debugging their implementation). A logical structure that is easy to navigate and that allows for quick reference works for both. Have a clear table of contents and an organized list of resources, and make sections, subsections, error cases, and display states directly linkable.

Great usability: Linkability demonstrated on Stripe’s API documentation.

Scannability: As Steve Krug claims in his book about web usability, Don’t Make Me Think, one of the most important facts about web users is that they don’t read, they scan. To make text easier to scan, use short paragraphs, highlight relevant keywords, and use lists where applicable.

Accessibility: Strive to make your API docs accessible to all users, including users who access your documentation through assistive technology (e.g., screen readers). Be aware that screen readers may often struggle with reading code and may handle navigation differently, so explore how screen readers read content. Learn more about web accessibility, study Web Content Accessibility Guidelines, and do your best to adhere to them.


You’ve worked hard to get to know your audience and follow best practices to leave a good impression with your API docs. Now, as a finishing touch, you can make sure your docs “sound” and look in tune with your brand.

Although API documentation and technical writing in general don’t provide much room for experimentation in tone and style, you can still instill some personality into your docs:

  • Use your brand book and make sure your API docs follow it to the letter.
  • A friendly tone and simple style can work wonders. Remember, people are here to learn about your API or solve a problem. Help them by talking to them in a natural manner that is easy to understand.
  • Add illustrations that help your readers understand any part of your API. Show how different parts relate to each other; visualize concepts and processes.
  • Select your examples carefully so that they reflect on your product the way you want them to. Playful implementations of your API will create a different impression than more serious or enterprise use cases. If your brand allows, you can even have some fun with examples (e.g., funny examples and variable names), but don’t go overboard.
  • You can insert some images (beyond illustrations) where applicable, but make sure they add something to your docs and don’t distract readers.
Think developer portal—and beyond

Although where you draw the line between API documentation and developer portal is still up for debate, most people working in technical communication seem to agree that a developer portal is an extension of API documentation. Originally, API documentation meant strictly the reference docs only, but then examples, tutorials, and guides for getting started became part of the package; yet we still called them API docs. As the market for developer communication grows, providers strive to extend the developer experience beyond API documentation to a full-fledged developer portal.

In fact, some of the ideas discussed above—like a developer forum or sandboxes—already point in the direction of building a developer portal. A developer portal is the next step in developer communication, where besides giving developers all the support they need, you start building a community. Developer portals can include support beyond docs, like a blog or videos. If it fits into the business model, they can also contain an app store where developers submit their implementations and the store provides a framework for them to manage the whole sales process. Portals connected to an API often also contain a separate area with landing pages and showcases where you can directly address other stakeholders, such as sales and marketing.

Even if you’re well into building your developer portal, you can still find ways to learn more and extend your reach. Attend and present at conferences like DevRelCon, Write The Docs or API The Docs to get involved in developer relations. Use social media: tweet, join group discussions, or send a newsletter. Explore the annual Stack Overflow Developer Survey to learn more about your main target audience. Organize code and documentation sprints, trainings, and workshops. Zapier has a great collection of blogs and other resources you can follow to keep up with the ever-changing API economy—you will surely find your own sources of inspiration as well.

I hope “The Ten Essentials for Good API Documentation” and this article gave you valuable insight into creating and improving your API documentation and inspire you to get started or keep going.

Categories: Technology

ABCs of IBM z/OS System Programming Volume 1

IBM Redbooks Site - Tue, 11/07/2017 - 08:30
Redbook, published: Tue, 7 Nov 2017

The ABCs of IBM® z/OS® System Programming is a 13-volume collection that provides an introduction to the z/OS operating system and the hardware architecture.

Categories: Technology

Apple 2017 fiscal fourth quarter -- the iPhone and iPad angle

iPhone J.D. - Mon, 11/06/2017 - 23:26

Apple starts a new fiscal year at the end of September every year.  Last Thursday, amid all of the media attention on the new iPhone X, Apple released the results for its 2017 fiscal fourth quarter (which ran from July 2, 2017 to September 30, 2017) and held a call with analysts to discuss the results.  This is typically a transitional quarter for Apple considering that so many sales take place in the October to December quarter that contains holiday sales.  Sales of the iPhone 8 and iPhone 8 Plus started September 22, 2017, so about a week of those sales were included in the fiscal fourth quarter, but of course it did not include any iPhone X sales.  Apple announced quarterly revenue of 52.6 billion (up from $46.9 billion a year ago) and quarterly net profit of $10.7 billion.  If you want to get all of the nitty gritty details, you can download the audio from the announcement conference call from iTunes, or you can read a rough transcript of the call prepared by Seeking Alpha.  Jason Snell of Six Colors also prepared a transcript.  Apple's official press release is here

As always, I'm not particularly interested in the financial aspects of this call.  But I'm always interested in the statements of Apple executives that pertain to the use of the iPhone and iPad.  Here are the items that stood out to me:


  • Apple sold almost 46.7 million iPhones in the last fiscal quarter.  By my count, that means that Apple has sold just over 1.25 billion iPhones as of September 30, 2017.  Apple sold its 1 billionth iPhone in July 2017, and it is amazing that it didn't take much more than a year to get to 1.25 billion.
  • Apple CEO Tim Cook stated in his prepared remarks that iPhone sales in the past quarter "exceeded our expectation."  The iPhone 8 Plus in particular "has gotten off to the fastest start of any Plus model," according to Cook.  "That, for us, was a bit of a surprise, and a positive surprise, obviously.  And so we’ll see what happens next."
  • Cook stated that initial demand for the iPhone X is "very strong for both direct customers and for our channel partners, which as you know are lots of carriers throughout the world."
  • When asked about the price of the iPhone X, the most expensive iPhone every sold, Cook stated:  "In terms of the way we price, we price to sort of the value that we're providing.  We're not trying to charge the highest price we could get or anything like that.  We're just trying to price it for what we're delivering.  And iPhone X has a lot of great new technologies in there that are leading the industry, and it is a fabulous product and we can't wait for people to start getting it in their hands."
  • Apple clearly believes that it will sell a lot of expensive iPhone X devices in the current quarter because it announced a prediction of 2018 Q1 sales (October-December) of $84 to $87 million.  That would easily be Apple's best financial quarter ever, and would be a big jump up from the $78.4 billion of 2017 Q1 and the $75.9 billion of 2016 Q1.  So when I update the following chart in three months, I expect to see a very tall line at the end:


  • Apple sold just over 10.3 million iPads in the last fiscal quarter. By my count, that means that Apple has sold over 381 million iPads as of September 30, 2017.
  • Last quarter was the first time in three and a half years that iPad sales started to increase. That trend continued this quarter with more sales in this fiscal fourth quarter than last fiscal fourth quarter.  I think that the best way to see this is to look at a chart that shows the average of four quarters of iPad sales over time. In the following chart, the blue line shows the actual iPad sales each quarter (in millions), and you can see the peaks every year in Apple's fiscal first quarter — the holiday quarter, when folks buy lots of iPads as presents. The green bars show the average of the current quarter and the prior three quarters, which gives you a better sense of iPad sales over time. As this chart shows, the iPad was introduced in 2010 and saw a sharp rise in sales until the end of calendar year 2013 (the beginning of Apple's fiscal year 2014), followed by a decrease in iPad sales over time, and then finally a slight increase in the past two quarters.  I'm sure that Apple hopes that the last two quarter are evidence that iPad sales are back on the upswing again.

Categories: iPhone Web Sites

ABCs of IBM z/OS System Programming Volume 3

IBM Redbooks Site - Mon, 11/06/2017 - 08:30
Draft Redbook, last updated: Mon, 6 Nov 2017

The ABCs of z/OS® System Programming is a thirteen-volume collection that provides an introduction to the z/OS operating system and the hardware architecture.

Categories: Technology

Review: iPhone X

iPhone J.D. - Mon, 11/06/2017 - 01:21

One of the early reviews of the iPhone X that I read a week ago was by Jason Snell of Six Colors titled "Tomorrow's iPhone Today."  I've been using the iPhone X for just over two days as I type this, and it really does feel like somebody used a time machine to show me what the iPhone of the future would look like.  Yes, it has many elements of the iPhone that we have known and loved for the past 10 years, but it is so much more advanced that it feels futuristic.  I've loved every iPhone that I have owned since my original iPhone 3G back in 2008, but this iPhone X is really something special.  It is more expensive than other models of the iPhone, but if you use an iPhone in your law practice and your personal life as much as I do, then it is worth it.

I discussed the major features of the iPhone X two months ago in this post.  Take a look at that post again if you want the list of what is new, including the new screen, Face ID, better battery, speed increase, wireless charging, true tone display, better camera, Bluetooth 5.0, etc.  Today, I want to just focus on my major impressions of the iPhone X — what makes the device feel so special. 

Where everybody knows your name

I'm sure that everyone has private information of some type on their iPhone, but of course attorneys will have tons of documents and other information that is confidential and subject to privileges such as attorney-client, work product, joint defense, etc.  Thus, attorneys need to use some sort of authentication on an iPhone.  For every iPhone that I have used before the iPhone X, I would pick up my iPhone and then, before using it, I had to pause for authentication.  Sometimes that meant typing a passcode.  Sometimes it meant putting my finger on the Touch ID button.

As you know, the iPhone X uses cameras and other technology that Apple calls Face ID for authentication.  What this means in practice is that it feels like you often don't have to worry about security at all.  It's like Norm entering the Cheers bar; just walk right in and everybody already knows your name (and they're always glad you came).  When I pick up the iPhone X to use it, the screen wakes as I lift the device, and then during the time that I am swiping my finger up to access the home screen, the iPhone X recognizes me and unlocks the device.  Or sometimes, all I want to do is look at my notifications, such as new emails or text messages.  I have my notification settings configured so that they show up on my lock screen, but do so in a way that if someone else picks up my iPhone, they don't see any of the content of the message (just the sender name).  On the other hand, if I pick up my iPhone, the iPhone X recognizes me and automatically expands each notification to also show me the subject line and the beginning of the email or message. 

(To configure this, go to the Settings App and in Notifications make the top option Show Previews When Unlocked, and in the individual app, such as Messages, turn on Allow Notifications and Show on Lock Screen.)

I love that my iPhone X is smart enough that when I pick it up, it immediately says "oh, that's just Jeff, he can go ahead an do whatever he wants" without me having to take any action at all — no entering a code, no authenticating a fingerprint, nothing.  And it is smart enough to do so even when there are slight variations in my appearance; I usually wear glasses, but the iPhone X recognizes me even if I have sunglasses on or even if I am not wearing glasses at all. 

Touch ID isn't perfect, especially if your fingers are wet.  Similarly, Face ID isn't perfect, and sometimes would fail to recognize me.  I noticed that the infrared camera would sometimes have difficulty when I was outside in a lot of sun, such as when I was at my daughter's soccer game on Saturday morning.  It also had some difficulties when I first woke up on Sunday and wanted to use my phone — perhaps my iPhone X was trying to tell me that I don't look my best when I first wake up.  When that happens, I just have to enter my passcode.  I understand that when you do this, the iPhone X will make slight adjustments to its sense of what you look like, so that Face ID improves over time.  Maybe next Sunday my iPhone X will be more forgiving of my looks.

But even though the first 48+ hours of Face ID may not be quite as accurate as Touch ID, I would never want to go back to using Touch ID after using Face ID.  When Face ID does work — which is the vast majority of the time — it really feels like you are just skipping the security step altogether.  Whether I am unlocking the phone, or using an app that checks for security such as my 1Password app (my password manager), it is magical and incredibly convenient for my iPhone X to see who I am and let me right in, without carding me first.  And considering that I probably use Face ID well over a hundred times every day, this is a major advantage of the iPhone X.


The iPhone X screen is breathtakingly amazing.  The edge-to-edge screen, with no bezel, lets you see so much more.  It's almost like getting the larger screen of one of the Plus-size iPhones in a device that feels the same in your hand as a non-Plus iPhone.  It's a taller phone, which means that you get a few more lines for apps that display info in a list form top-to-bottom.  This includes some of the apps that I use the most on my iPhone, such as Mail, Safari, Notes, Twitter, 1Password, Music, Facebook, etc.  Videos and photos look fine when the iPhone X is turned on its size in landscape mode, but other apps do seem unusually wide.  But other than videos and photos, I virtually never have my iPhone turned to landscape mode anyway.  In portrait mode, the extra space is much appreciated.

And it's not just quantity, it's quality too.  The OLED screen is unlike anything I've ever seen on a phone before, including prior Android phones with an OLED screen.  Apple has done an amazing job with this thing.  The black are perfectly black, and colors are vivid (but not over-saturated).  Whether you are looking at photos or videos, or simply using the iPhone to get work done, everything just looks amazing.

The iPhone X also uses a True Tone display, which adjusts colors based upon the surrounding light.  I love that display on my iPad Pro, and it is nice to have it on my iPhone too.  White backgrounds always look like nice white backgrounds.

I cannot really post a picture that will give you a sense of how good the iPhone X screen looks because you'll be limited by the screen of whatever you are using to read this post.  Either go to an Apple Store to see it yourself, or just trust me — it is amazing.


I celebrated my birthday yesterday, so I'll admit that billable hours were not high on my list of priorities this weekend.  But I did do some work, and I can already tell that the iPhone X will help me to be more productive. 

First, as noted above, the taller screen lets you see more at one time, which is a nice productivity boost.  For example, when looking at a list of emails, I can see two additional emails.  When reading the text of an email, I can see even more of the message.

Second, multitasking works MUCH better on the iPhone X.  There is a short line across the bottom of most screens.  That mostly serves as a reminder that you can swipe up to access the home screen or do other functions that in the past would be accomplished by pressing a Home Button.  But if you swipe your finger from left to right across that line (i.e., across the bottom of the screen) you switch to prior apps that you have used.  Yes, I know that on earlier versions of the iPhone you can 3D Touch on the left side of the screen to invoke the app switcher, but I've always found that gesture awkward and a little slow on a naked iPhone and sometimes almost impossible to do on an iPhone in a case.  Swiping along the bottom of the iPhone X is vastly superior.

And then of course, as with every new iPhone, everything works even faster, so you spend less time waiting to do work.  Combine that with Face ID, and this means that you can get in, get your work done, and get out much more efficiently.

Fun with the TrueDepth camera

App developers cannot access everything that Apple can access in Face ID, but they do have access to the TrueDepth camera and the speedy A11 processor, which means that apps can analyze your facial expressions.  In a very creative demonstration of what that means, Apple included Animoji with the Messages app, allowing you to make an animated character mimic your facial expression.  You can either create a single image, or for even more fun create a short 10 second video in which the character speaks your words and uses your expressions.  Creative folks on Twitter soon realized that this means that you can create Animoji Karaoke (Harry McCracken was one of the first).  Here is an example of a good one, using multiple Animoji to sing Bohemian Rhapsody:

This is just the beginning.  When David Pogue of Yahoo reviewed the iPhone X, he had access to a pre-release version of Apple's Clips app which uses the TrueDepth camera like a virtual green screen that can put your face in other environments, such as on the Millennium Falcon.  And those are just apps from folks at Apple, who have access to the iPhone X for a while now.  Clever third parties are going to come up with all sorts of fun uses for this technology.

No, the TrueDepth camera is unlikely to help you in your law practice, unless someone out there is being more creative than I am right now.  But it sure is a lot of fun.  My kids had a great time making silly faces with the Animoji characters, and I even received a birthday greeting from my three year old nephew who was very cute as an alien.

Come on and zoom-a-zoom-a-zoom-a-zoom

I've always been jealous of the zoom camera on the Plus versions of the iPhone, but those phones are just too darn large for me to want to ever own one.  With the iPhone X, I finally have an iPhone that feels like the right size in my hand while also having two cameras, the traditional wide-angle camera and the telephoto camera, both with optical image stabilization.  I love taking pictures and video with my iPhone, but it was often frustrating to me to not have a zoom lens.  (Sure, you could do a digital zoom, but the picture quality decreased rapidly as you zoomed in.)  You can now get full quality even with a 2x zoom, and if you need to zoom in a little bit more you can do so with much better results than ever before. 

This past Saturday, when I attended my daughter's soccer game, I used the iPhone X to take a video of game highlights, including the two goals that she kicked (yeah!).  I kept my iPhone X in 2x mode and got a great results with the 4K video, even when she was far across the soccer field from where I was watching. 

Feels great in the hand

With a width of 2.79", the iPhone X take up essentially the same amount of space across your hand as an iPhone 7 or similar non-Plus models of the iPhone (2.64" for the iPhone 7).  The glass black feels very similar to the Jet Black version of the iPhone 7, and also feels similar to the glass black on the old iPhone 4.

I used a case with my iPhone 7, mainly to add some friction to decrease the chance that I drop it.  For now, I'm using the iPhone X without a case.  I made decide to add a case in the future, and of course if you use a case it will be the case that you are feeling.  But if you don't use a case, the iPhone X feels great, and you can really feel and appreciate the build quality and care that went into creating it.

Other advantages

The built-in speaker is louder and better-sounding.  Most of the time I use AirPods, but sometimes if I'm listening to a podcast or song when nobody else is around, I'll just set down my iPhone and turn up the volume.  That works better with the iPhone X.

I haven't used the iPhone X long enough to do battery tests, but I'm encouraged by Apple saying that the iPhone X lasts two more hours than the iPhone X.  I suspect that the battery is larger, but that's not the full story.  I noticed that when I'm not looking at my iPhone X for a while, it pays attention to that and turns of the screen.  My iPhone 7 has no idea if I'm looking at the screen or not, so it keeps the screen on much longer when I'm not using the device, wasting battery life.

I know that this iPhone X has wireless charging.  At this point, I don't see a need for that; plugging a Lightning cable into the bottom of an iPhone doesn't seem like that big of a deal.  But as wireless charging becomes more of a thing, it might be something that I find useful, either at home if I purchase a charging device or in a restaurant or other public facility.  For now, the jury is out on this feature, but I suppose it could be nice to have.

I also haven't yet had a chance to try Bluetooth 5.0, but this is one feature that I definitely look forward to using when compatible devices become available.  While Bluetooth 4.2 has a range of up to about 30 feet, Bluetooth 5.0 has a range of up to about 260 feet.  If Apple comes out with Bluetooth 5.0 AirPods with much longer range, that would be fantastic.


There really isn't much of the way of bad news with the iPhone X, other than the fact that you have to pay more to get these extra features.  And although I have a lot of muscle memory associated with the traditional iPhone Home Button, it only took me about a day to get used to the new gestures such as swiping up instead of pressing a Home Button.  Indeed, last night, as I was taking some screenshots with my iPhone 7, I found myself swiping up on the bottom of the iPhone 7 to exit an app instead of pressing the button, which is clear proof that it doesn't take long to get used to the new gestures.

The advantages of the iPhone X — especially the better screen and Face ID — are fantastic, making this a substantial upgrade over prior models.  If, like me, you use your iPhone a large number of times a day, throughout the day and every day, I can highly recommend the iPhone X.  What a great product.

Categories: iPhone Web Sites

In the news

iPhone J.D. - Fri, 11/03/2017 - 00:42

Apple starts selling the iPhone X at 8am today.  And because of time zones, that means that folks in Sydney, Australia (which is 15 hours ahead of the Eastern Time Zone) have been using an iPhone X for a while now, and Apple has a few pictures.  Shortly after Apple started taking pre-orders one week ago, shipping times slipped to 5-6 weeks.  Apparently Apple is working hard to ramp up production, because as I type this it is now down to 3-4 weeks.  Of course you can also show up at an Apple Store today to buy one without a pre-order, but I'm sure that supply is very limited, so unless you are already standing in line as you are reading this in the early hours of Friday morning, I suspect that it is too late for you to get one today.  And now, the news of note from the past week:

  • If you have any interest in using your iPhone to control lights and more in your home, Florida attorney Katie Floyd and California attorney David Sparks had a fantastic episode of their Mac Power Users podcast in which they speak with home automation expert Robert Spivack.  It was good to hear that Spivack is as much of a fan of Lutron Caséta light switches as I am.  (My review.)
  • New York attorney Nicole Black discusses on the MyCase blog five third party Apple Watch apps that lawyers might find useful.  At this point, however, I think it is really the built-in Apple Watch apps that attorneys will use most of the time.
  • Rene Ritchie of iMore notes that the iPhone X lacks the setting to display a battery percentage in the top corner, but as a workaround you can see it when you bring up the Control Center.
  • Apple Pay works a little differently on the iPhone X, as Rene Ritchie of iMore explains.
  • Speaking of Apple Pay, Bryan Wolfe of AppAdvice notes that you will soon be able to use Apple Pay in some new locations, including Saks Fifth Avenue, Dick's Sporting Goods and Albertson's.
  • My favorite app for listening to podcasts, Overcast, was updated to version 4.0 yesterday.  Federico Viticci of MacStories explains what is new.
  • Apple CEO Tim Cook was interviewed by NBC Nightly News anchor Lester Holt to discuss Apple specifically (including the iPhone X) and the tech industry in general.
  • Apple has a special page of its website devoted to iPhone X tips.
  • Lance Ulanoff of Mashable talked to a few Apple executives to get the backstory on the creation of the iPhone X.
  • For folks who want a new iPhone but want a more traditional model with Touch ID and without the $1000+ price tag, Apple now has the new iPhone 8.  Jason Snell of Six Colors wrote this review.
  • As noted by Trevor Daughterty of 9to5Mac, a neat AR feature was added to the Amazon app this week.  Tap the camera icon at the top and then tap AR view.  Now you can select lots of different products and see how each would look in a room in AR.  Once you place the object, you can walk around it, zoom in and out, etc.  Neat stuff.
  • And finally, Apple came out with a new commercial for Apple Music this week, and I really like it.  It features the Apple Music logo (two eighth notes) worked into animations of famous albums and artists.  Every time I watch the ad I pick out something else; for example, the homage to Fleetwood Mac's Rumours album cover goes by in such a fraction of a second that I didn't even see it the first two times i watched the video:

Categories: iPhone Web Sites

What the Failure of New Coke Can Teach Us About User Research And Design

A list Apart development site - Thu, 11/02/2017 - 08:46

In the late 1970s, Pepsi was running behind Coca-Cola in the competition to be the leading cola. But then Pepsi discovered that in blind taste tests, people actually preferred the sweeter taste of Pepsi. To spread the word, Pepsi ran a famous advertising campaign, called the Pepsi Challenge, which showed people tasting the two brands of cola while not knowing which was which. They chose Pepsi every time.

As Pepsi steadily gained market share in the early 1980s, Coca-Cola ran the same test and found the same result—people simply preferred Pepsi when tasting the two side by side. So, after conducting extensive market research, Coca-Cola’s solution was to create a sweeter version of its famous cola—New Coke. In taste tests, people preferred the new formula of Coke to both the regular Coke formula and to Pepsi.

Despite this success in tests, when the company brought New Coke to market, customers revolted. New Coke turned out to be one of the biggest blunders in marketing history. Within months, Coke returned its original formula—branded as “Coca-Cola Classic”—to the shelves.

In the end, sales showed that people preferred Coke Classic. But Coca-Cola’s research predicted just the opposite. So what went wrong?

The tests had people drink one or two sips of each cola in isolation and then decide which they preferred based on that. The problem is, that’s not how people drink cola in real life. We might have a can with a meal. And we almost never drink just one or two sips. User research is just as much about the way the research is conducted as it is about the product being researched.

For the purposes of designing and researching digital services and websites, the point is that people can behave differently in user research than they do in real life. We need to be conscious of the way we design and run user research sessions and the way we interpret the results to take real-life behavior into account—and avoid interpretations that lead to a lot of unnecessary work and a negative impact on the user experience.

To show how this applies to web design, I’d like to share three examples taken from a project I worked on. The project was for a government digital service that civil servants use to book and manage appointments. The service would replace a third-party booking system called BookingBug. We were concerned with three user needs:

  • booking an appointment;
  • viewing the day’s appointments;
  • and canceling an appointment.
Booking an appointment

We needed to give users a way to book an appointment, which consisted of selecting a location, an appointment type, and a person to see. The order of these fields matters: not all appointment types can be conducted at every location, and, not all personnel are trained to conduct every appointment type.

The first iteration of the booking journey, with three select boxes in one page.

Our initial design had three select boxes in one page. Selecting an option in the first select box would cause the values in the subsequent boxes to be updated, but because it was just a prototype we didn’t build this into the test. Users selected an option from each of the select boxes easily and quickly. But afterwards, we realized that the test didn’t really reflect how the interface would actually work.

In reality, the select boxes would need to be updated dynamically with AJAX, which would slow things down drastically and affect the overall experience. We would also need a way to indicate that something was loading—like a loading spinner. This feedback would also need to be perceivable to visually-impaired users relying on a screen reader.

That’s not all: each select box would need to have a submit button because submitting a form onchange is an inclusive design anti-pattern. This would also cover scenarios where there is a JavaScript failure, otherwise, users would be left with a broken interface. With that said, we weren’t thrilled with the idea of adding more submit buttons. One call to action is often simpler and clearer.

As mentioned earlier, the order in which users select options matters, because completing each step causes the subsequent steps to be updated. For production, if the user selected options in the wrong order, things could break. However, the prototype didn’t reflect this at all—users could select anything, in any order, and proceed regardless.

Users loved the prototype, but it wasn’t something we could actually give them in the end. To test this fairly and realistically, we would need to do a lot of extra work. What looked innocently like a simple prototype gave us misleading results.

Our next iteration followed the One Thing Per Page pattern; we split out each form field into a separate screen. There was no need for AJAX, and each page had a single submit button. This also stopped users from answering questions in the wrong order. As there was no longer a need for AJAX, the related accessibility considerations went away too.

The second iteration of the booking journey, with a separate page for each step.

This tested really well. The difference was that we knew the prototype was realistic, meaning users would get a similar experience when the feature went into production.

Viewing the day’s appointments

We needed to give users a way to view their schedule. We laid out the appointments in a table, where each row represented an appointment. Any available time was demarcated by the word “Available.” Appointments were linked, but available times were not.

The schedule page to view the day’s appointments.

In the first round of research, we asked users to look at the screen and give feedback. They told us what they liked, what they didn’t, and what they would change. Some participants told us they wanted their availability to stand out more. Others said they wanted color-coded appointment types. One participant even said the screen looked boring.

During the debrief, we realized they wanted color-coded appointments because BookingBug (to which they had become accustomed) had them. However, the reason BookingBug used color for appointments was that the system’s layout squeezed so much information into the screen that it was hard to garner any useful information from it otherwise.

We weren’t convinced that the feedback was valuable. Accommodating these changes would have meant breaking existing patterns, which was something we didn’t want to do without being sure.

We also weren’t happy about making availability more prominent, as this would make the appointments visually weaker. That is, fixing this problem could inadvertently end up creating another, equally weighted problem. We wanted to let the content do the work instead.

The real problem, we thought, was asking users their opinion first, instead of giving them tasks to complete. People can be resistant to change, and the questions we asked were about their opinion, not about how to accomplish what they need to do. Ask anyone their opinion and they’ll have one. Like the Coca-Cola and Pepsi taste tests, what people feel and say in user research can be quite different than how they behave in real life.

So we tested the same design again. But this time, we started each session by asking users questions that the schedule page should be able to answer. For example, we asked “Can you tell me when you’re next available?” and “What appointment do you have at 4 p.m.?”

Users looked at the screen and answered each question instantly. Only afterward did we ask users how they felt about it. Naturally, they were happy—and they made no comments that would require major changes. Somewhat amusingly, this time one participant said they wanted their availability to be less prominent because they didn’t want their manager seeing they had free time.

If we hadn’t changed our approach to research, we might have spent a lot of time designing something new that would have had no value for users.

Canceling an appointment

The last feature involved giving users a way to cancel an appointment. As we were transitioning away from using BookingBug, there was one situation where an appointment could have been booked in both BookingBug and the application—the details of which don’t really matter. What is important is that we asked users to confirm they understood what they needed to do.

The confirm cancellation page.

The first research session had five participants. One of those participants read the prompt but missed the checkbox and proceeded to submit the form. At that point, the user was taken to the next screen.

We might have been tempted to explore ways to make the checkbox more prominent, which in theory would reduce the chance of users missing it. But then again, the checkbox pattern was used across the service and had gone through many rounds of usability and accessibility testing—we knew that the visual design of the checkbox wasn’t at fault.

The problem was that the prototype didn’t have form validation. In production, users would see an error message, which would stop them from proceeding. We could have spent time adding form validation, but there is a balancing act between the speed in which you want to create a throwaway prototype and having that prototype give you accurate and useful results.


Coca-Cola wanted its world-famous cola to test better than Pepsi. As soon as tests showed that people preferred its new formula, Coca-Cola ran with it. But like the design of the schedule page, it wasn’t the product that was wrong, it was the research.

Although we weren’t in danger of making the marketing misstep of the century, the design of our tests could have influenced our interpretation of the results in such a way that it would have created a lot more work for a negative return. That’s a lot of wasted time and a lot of wasted money.

Time with users is precious: we should put as much effort and thought into the way we run research sessions as we do with designing the experience. That way users get the best experience and we avoid doing unnecessary work.

Categories: Technology

Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.1

IBM Redbooks Site - Wed, 11/01/2017 - 09:30
Draft Redbook, last updated: Wed, 1 Nov 2017

Continuing its commitment to developing and delivering industry-leading storage technologies, IBM® introduces the IBM Storwize® V7000 solution powered by IBM Spectrum™ Virtualize, which is an innovative storage offering that delivers essential storage efficiency technologies and exceptional ease of use and performance, all integrated into a compact, modular design that is offered at a competitive, midrange price.

Categories: Technology

Implementing the IBM System Storage SAN Volume Controller with IBM Spectrum Virtualize V8.1

IBM Redbooks Site - Wed, 11/01/2017 - 09:30
Draft Redbook, last updated: Wed, 1 Nov 2017

This IBM® Redbooks® publication is a detailed technical guide to the IBM System Storage® SAN Volume Controller, which is powered by IBM Spectrum™ Virtualize V8.1 IBM SAN Volume Controller is a virtualization appliance solution, which maps virtualized volumes that are visible to hosts and applications to physical volumes on storage devices.

Categories: Technology

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

IBM Redbooks Site - Wed, 11/01/2017 - 09:30
Draft Redbook, last updated: Wed, 1 Nov 2017

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

Categories: Technology

ABCs of IBM z/OS System Programming Volume 2

IBM Redbooks Site - Wed, 11/01/2017 - 09:30
Draft Redbook, last updated: Wed, 1 Nov 2017

The ABCs of z/OS® System Programming is a thirteen volume collection that provides an introduction to the z/OS operating system and the hardware architecture.

Categories: Technology


Subscribe to www.hdgonline.net aggregator