danbricklin.com/log

Starting June 19, 2013
MassTLC unConference session on Responsive App Design, Responsive App Layout, What Jeff Bezos and John Henry should read to prepare for their new ownership, More about web app speed, Are mobile web apps really slow?, What's holding back HTML5 from mobile dominance?, What it looked like to surf the web in 1994, Mobile device feature war, Why Alpha Anywhere matters in today's mobile world, Live streaming a town meeting is a good thing, A big change in what I'm doing
19Jun13
2013_06_19.htm
Friday, November 8, 2013 
MassTLC unConference session on Responsive App Design [link]
Just as it has for the three years before, this fall the Massachusetts Technology Leadership Council ran its "Innovation unConference". They have a web site, www.masstlcuncon.org, that explains it all, and I posted lots of photos to Flickr as I have in the past.

This time, I proposed and moderated a session on Responsive App Design. I started things off by showing my video on the topic to get everybody up to speed with what I meant by the term. (On this blog I had called the topic "Responsive App Layout", but I've since switched to the more common word "Design", use the URL www.responsiveappdesign.org for the companion web site, and redid the video to better show the example app.)

In the session, we had a lively, useful discussion, which one of the attendees kindly captured on a flip chart that the conference had provided in the room. There were things worth sharing, so I'm reproducing what was written with a little embellishment:

Contexts / Break Point (what to take into account for different designs)
Width / Columns / Landscape / Portrait
Sighted / Blind / Color blind
Mouse / Touch
User standing / sitting / walking / computer mounted on a wall
Language orientation (e.g., left to right vs. right to left)
One-handed use vs. two-handed use
Google Glass, Voice controls, Wrist devices
The user's state of mind: Calm, stressed, etc.
Location: Inside, outside, driving, moving

Examples of apps to learn from
Dark design
Inpath / Pathapp (for innovative controls)
Prezi
WGBH
Grid on iOS
Runkeeper
Messaging apps (Apple: context changing UX)
Tandem Seven (design firm HQ in Massachusetts)
UXArchive.com: Has lots of examples of UX of different apps organized by tasks (screenshots)

Apps vs. Sites:
Sites have a Presentation Layer
Apps also have major Control Layers and Input Layers

Don't forget different expectations in each OS for user interface stye
Android vs. iOS vs. ...?

"Write Once, QA Many"

UX control techniques
Ease of Discoverability vs. Learned / Taught

Action Items
Design Guidelines (we're too soon for standards)
Need more good/successful examples of business apps

That's it. One of the attendees told us about how his company had worked quite hard on each variation of their native apps for each platform and the thinking that went into each input control and interaction. They are in an app category (messaging) that is quite competitive and where specifics of the UI is one of the distinguishing features of the product and what makes it worthwhile for users to choose their product instead of just using the built-in app. I hope I can get a podcast with him at some point to hear what they went through.

Thursday, October 17, 2013 
Responsive App Layout [link]
I've been writing a lot here about using HTML5 for business web apps, especially mobile apps. A benefit of HTML5 is that apps that run on multiple platforms are usually easier and less expensive to write than writing in native code for each platform. A challenge is having that one codebase adjust to the screen size and orientation differences of the different devices it runs on. This is more extensive than that usually needed by informational web sites traditionally targeted for Responsive Web Design. Developers need to take into account not just screen width but also screen height, as well as on- and off-screen controls.

I've produced a video, "Responsively Laying Out Web Apps", that explores this issue, embedded below. I've also written an essay about it, "Responsive Web App Design".


Video on YouTube
Feedback that I've gotten is that this is an important issue that developers need to deal with. The video also shows how we have started to address it on the tools side by adding new capabilities to Alpha Anywhere.

Monday, August 19, 2013 
What Jeff Bezos and John Henry should read to prepare for their new ownership [link]
In the last month, two major metropolitan newspapers were purchased by new owners: The Boston Globe by John Henry and the Washington Post by Jeff Bezos. Both new owners are individuals, not some investment entity looking for a purely financial return. You have to assume that they both view this as more than just a financial investment and that they realize that they are now in a different part of the news business than they were when they were just the subject of reporting.

There has been a lot of speculation about what each of them intends to do. What direction will they take the "papers"? How will they react when confronted with situations like those that have involved their predecessors? (For example, the Post had to decide what to do during the Watergate investigation and the Globe had to decide how much to invest in the early Boston.com web site.) How will they guide their acquisitions as technology evolves? (Jeff brought us Amazon.com and John put Moneyball into practice.)

They are both new to the news business.

I have a suggestion for them both: As part of your "homework" as you enter this field, please read Christopher Daly's history of journalism in the USA, "Covering America" (Here are Amazon links to the Kindle version and the Hardcover version).

I'm sure the $21.99 price of the Kindle version won't be a problem (Jeff probably gets a discount). The hardcover version is a little heavy to carry around (I just weighed my copy: a little over 2 1/2 pounds), but if either of them wants a physical copy signed by the author, let me know and I'll buy them one and get Chris to inscribe it for them.

Why this book? It's not just because Chris is my next door neighbor, or that he's a professor of journalism at Boston University, or that he used to be the New England correspondent for the Washington Post, or that the book is being used as a textbook by journalism students around the country. It's because the book covers the constant evolution of the world they are now joining and shows them what they, personally, are now a part.

"Covering America" is a book about the people that developed the many business models we now take for granted (or think of as quaint now that their time has come and gone). It is a book about the practitioners of the craft as it evolved, from Benjamin Franklin and Thomas Paine to Joseph Pulitzer, Nellie Bly, and William Randolph Hearst to Bill Paley and Ed Murrow to Ted Turner and Josh Marshall. The book brings dozens and dozens of people to life -- lives that will help Jeff and John chart their place in this ongoing sequence of very special individuals. It will give them background to inspire them to use their own special gifts (not just financial, but industry-changing) to help evolve a calling that is important enough to be in the Bill of Rights.

"Covering America" shows how journalism evolved, both in its practice and as a business. The changes we are seeing now are no more drastic than those brought about by the telegraph, the powered rotary press, or radio.

The book is not a boring recitation of facts. Chris spent time as a feature writer, and this book is written as an interesting narrative, weaving lively biographies with the historical context.

You can see Chris interviewed by the dean at the Columbia School of Journalism the spring of last year on CSPAN: "Book Discussion on Covering America: A Narrative History of a Nation's Journalism" (about an hour long -- note that the book is a lot more fun to read than watching an interview like this on stage at a university). Starting at about 28:00 there is discussion about who will be owning newspapers in today's world. (The hardcover came out in early 2012, but the Kindle version didn't come out until this year.)

Chris blogs at www.journalismprofessor.com and tweets as @ProfDaly.

Friday, July 26, 2013 
More about web app speed [link]
It seems that there was a lot of discussion about the already hot topic of HTML5 vs. native that was sparked by Drew Crawford's article "Why mobile apps are slow." It's amazing how one good blog post can have a big effect, bringing the author into a worldwide conversation with authority that stems from their careful writing.

As a result of my comments, I've had some interesting emails back and forth with Drew which has helped me understand some of the feelings people have with respect to this issue. There is a desire that many developers have to craft something new and make it as close to their vision as possible. The goal is the instantiation of the vision, crafted as best as possible. In this case, it is not uncommon that you would need to drop into lower-level tools to implement something that had not been envisioned when the higher-level tools were built. For example, in the old Visual Basic days, it was not uncommon for someone to need to handcraft a control in C or C++ code to implement a behavior that was not already built-in. (Since most VB developers were probably not up to doing this, or didn't have the time, a nice market for those new controls emerged.) The same is still true. For example, in the iOS world, many of us "roll our own" custom controls to get exactly the user experience and functionality that a product needs. (My Note Taker HD app is filled with such controls. I often fall into this "craft the new vision" camp.)

However, for a wide range of applications, especially those "bread and butter" ones that every business needs, with customizations tuned to the particular needs of the business, but generally of the same genre, the times when you need to create new controls are few and far between. The innovation that comes with creating those apps is in the data design, the flow of control, the organization of displays, the integration with (and choice of) external data and services, and the close fit with the needs of the user. In those cases, development systems that anticipate the appropriate generic set and variations of controls and optimize for their assembly into a working app are often "the right tools for the job". A good choice of the controls in the set and the built-in variations can give the developer a comfortable space in which to concentrate on the other aspects of the app that may be requirements for success. Getting the extra polish of some new UI tweak available only to native code, in these cases, often doesn't outweigh productivity benefits of systems that may be built on HTML5 and other technologies. (This also relates to my discussion about "How HTML wins" and "Why Alpha Anywhere matters" -- Alpha Anywhere is a development system that targets HTML5 with a set of controls and variations tuned to business applications. It also relates to the value of the JavaScript language in a programming sense, as I discussed in my previous post.)

In business, there is often another factor. As I pointed out in the podcast interview I did with Scott Hanselman a few weeks ago, sometimes it's more important to just get an application out the door so it can be used before the short-term reason for its existence has passed. (I talk about that at 18:14, but the whole podcast has been getting good reviews.)

I also realized that there's another reason for web apps vs. native: Browsers have always had to deal with content (e.g., web pages) authored in the past and not updated for the latest release of the browser. Backwards compatibility has been a major design requirement for the people who create the browsers. This is why you can still read this web site which is authored using a tool (Trellix Web) last modified in the year 2000 and which creates HTML targeted for the browsers popular at the time (that is, even older). You can even read it on devices running the most recent version of iOS and Android.

The ability in the HTML/CSS/JavaScript world to have old "code" that runs correctly each time you use it for many years, and to choose the time to upgrade which browser features you take advantage of, is a real help to the developer. Any developer who has been forced to revisit old code just to continue running on the latest version of an operating system knows how helpful this ability can be. In the business world, stung by the costs of Y2K and other "flag day" upgrades, this is an important consideration. Also, the open nature of web technologies means that different parties can keep backward compatibility working, lessening the dependence on a single provider.

Thursday, July 11, 2013 
Are mobile web apps really slow? [link]
My co-worker Bob Moore (@remoorejr) pointed out an essay written by iOS developer Drew Crawford titled "Why mobile apps are slow". Drew goes to great lengths to give us lots of data about speed differences between various "native" code execution and JavaScript. This data, together with some architectural discussions about the overhead of garbage collection in a memory-constrained environment, helps show why for all sorts of computing and/or memory intensive tasks JavaScript executes much slower than native, let's say at least five times slower. On ARM CPU-powered mobile devices, which are much slower than desktop x86 devices, where you need every bit of speed possible in many cases, this can be a deal breaker he feels.

But is that really the whole story? I don't believe that this presents the whole story. While it is true that for doing general computation of mathematical operations native code should be able to run circles around JavaScript (and compute those circles while doing it) that ignores what type of operations are performed in many apps and where JavaScript-based apps often equal or beat native code.

First, a bit about my background: I've been coding for well over 45 years. I've written in FORTRAN, assembler for numerous computers, C, C++, Objective-C, JavaScript, Perl, Visual Basic, and many more languages, shipping products on all of them to real users. I have built an entire, feature-full spreadsheet in JavaScript that runs even on IE 6 and the One Laptop Per Child's XO (two very challenging environments for JavaScript). I have successful, complex native-code apps in the Apple App Store. This means I at least have some perspective from the real world.

For most of what we are talking about, JavaScript does not execute in a vacuum. It runs in a browser. That browser environment brings a lot to the table. The applications you are coding are often ones that lend themselves to what a browser is good for: Presenting information.

The browser development community has been laser-focused on speed of many common operations. Those browser developers have also been pushed by web developers to expand the visual flexibility of what a browser can render directly. So, from the first, browsers did simple rich text rending, with simple but useful dynamic layout capabilities. Even the really early browsers had basic text editing built-in. (See "Video of Bob Frankston's tour of the WWW in 1994".) Today's browsers, with CSS3, have amazing capabilities, including animation and transforms accelerated by GPU hardware, and flexible font control. These are things that are really hard to program yourself, especially if you want them to render quickly. Really hard. (I helped lead a company in the 1990's where we had to implement our own complete text layout engine in C++. That is not something to do lightly or in "just a few months".) For many applications, advanced text layout is a requirement, so using a browser component to do that part speeds development and, because development time is a real factor in almost all projects, can result in a better product. How many iOS apps don't use rich text or complex dynamic layouts because it has been so hard to do those things in native code?

So, one argument in favor of web apps is that many of the common, tough-to-program operations are carefully coded by top programmers who are devoting their careers to fine-tuning that operation. Browsers are constantly being upgraded more and more of this important functionality built-in, including rich-text editing and 3D graphics rendering. If your application's performance is gated by those operations, a web app you could figure out how to write yourself may outperform what you could write yourself in native code.

Another benefit of JavaScript is that many of the common operations needed for many types of applications, such as text processing, are built into the language with a natural syntax. Slowly but surely common operations like lookups and string handling have been added natively to traditional languages. Only slowly has Objective-C been seeing strings and hash-tables becoming more than libraries accessed like other objects. This means that handling of modern cases (e.g., characters taking up more than one byte) happens naturally, efficiently, and hopefully more bug-free. Easy to write string handling is why languages like Perl became so popular when string handling became more important than number handling.

It has been a long-known lesson in programming that different languages for the same algorithm give you factors of a few in improvement (let's say 5-10x here), but that improved algorithms give you orders of magnitude improvement (10-100x). That is, if you can approach a problem in a different way, or rethink it after you've coded it and have seen what's really needed, you can often get enormous performance gains vs. just running the same operations somewhat faster. Using JavaScript, in a browser with CSS3, can often make it easier to get those types of improvements. Of course, if the things that a browser and JavaScript provide are not appropriate for your task, then they may push you the other way, so developers can't just blindly say JavaScript is always best.

There is the question of whether adding special subsets of JavaScript (e.g., asm.js) for speed is just showing that JavaScript isn't fast enough. I've used the "lower level" C-style coding in my Objective-C apps when performance dictated it, and assembly code in my C programs for the time-critical inner loops. I see no problem, and only advantages, with the ability to take the most time-critical sections of computation and "hand coding" them in a language or style more appropriate for that particular task. I don't see that as mandating writing the whole app that way or tainting the main language that is best suited to the rest of the application.

There are many situations where the benefits of an HTML/JavaScript/CSS implementation outweigh the performance hits in other areas. As with all development, it is the job of a good developer to use the right tool for the job when possible. There is no one "best" tool that works for everything. Any programmer ignoring JavaScript is doing themselves a disservice.

Monday, July 1, 2013 
What's holding back HTML5 from mobile dominance? [link]
There are so many articles saying that HTML5 is the way to go for mobile development, but you still see so many apps being written in native code. What will it take to finally make HTML be as dominant on mobile as it is on the desktop? Does it just need a more complete JavaScript framework? What about easier connection of JavaScript to a SaaS database?

I thought about this from an historical angle and wrote an essay. Read "How HTML wins" in the Writings section of this web site.

The main point is: What we are missing are the easy to use, non-coding systems to let a wider range of people develop and deploy apps for mobile devices. This situation of authoring systems that cater to the needs of "domain experts" rather professional programmers leading to large increases in custom computer applications is the common case, not the special case, in computing history. It helped fuel HTML on the desktop as it has for other modes of computing in times before it and will in the mobile and touch-enabled world.

Saturday, June 29, 2013 
What it looked like to surf the web in 1994 [link]
I just posted a video, along with explanation, that I took on May 30, 1994, of my friend Bob Frankston surfing the web using NCSA Mosaic, the popular browser of the time. (Netscape was founded less than two months before.) It is a good example of how far we have come, and what an early technology looks like.

See "Video of Bob Frankston's tour of the WWW in 1994" in the Writings section of my web site.

This, or something like it, is a must for all sorts of classes about computers or technology. So many people laugh at early technology and need to be reminded how early versions of important technology in their lives evolved and continue to evolve.

Thursday, June 27, 2013 
Mobile device feature war [link]
Allen Pike, a developer in Vancouver, BC, posted an essay that has been getting some attention: "iOS 7: Catch me if you can". He posits that some of the new UI features and design guidelines that Apple has shown for iOS 7 are hurdles that will encourage native, iOS development (and deployment, and device purchase). Those changes make it hard to recreate the same effects in a browser app (today, for cross-device techniques like PhoneGap/Cordova) or on lesser hardware than Apple's latest and best (lessening the draw of inexpensive Android, etc., devices). Those features include multiple planes affected by motion, translucency with blur, and complex physics-driven animations.

Separately, I've seen discussion about the benefits of a feature in some new Samsung devices: What they call "Air View". It is apparently similar to what Sony released last year on the Xperia sola and called "Floating touch". (See Sony's explanation of how it works electrically here.) This is the ability for the device to detect a finger hovering over, but not touching, the screen with enough precision to do many of the common desktop mouse "tool-tip" and "bubble help" effects.

The lack of this "hover" capability has been a real problem for mobile app UI designers. Reactions to hovering are a well-known and popular way to expose otherwise hidden UI features without cluttering up the main display. With apps that break ground on new areas of use because of being mobile or because of cleverness that run on tiny, real-estate craving touch screens this is a double loss.

Apple has not shown an interest in this feature, even though it looks like they could make hardware to support it.

From an app designer's viewpoint, especially in the business world where efficiency can translate into big dollars and where the choice of hardware for a particular application can be mandated, which of these two directions may be more compelling? How developers react can make a difference. Sony went the route of putting it in the browser and Android as a standard of some sort. I'm not sure what Samsung has done.

It will be interesting to see who will be able to be the leader that developers follow. As Apple has shown, having the right apps and having them run well can be a way to draw users. Will anybody notice Samsung (and Sony -- it's been a year and I hadn't heard much buzz about this)? Or will it be the sexier eye-tracking from Samsung? Does that have such UI value or is it just sizzle?

Like many developers, I'm carefully looking at the implications of the switch to iOS 7 for my apps. There is a cost to retooling. Is the benefit enough, or should I look instead to new multi-platform apps or even Samsung/Sony-specific ones? Samsung has a big market share... Old-style-looking iOS apps will hopefully continue to work and be useful on both older and newer devices. Decisions, decisions. This happens every time Apple releases a new version of iOS. This time the calculus for us developers is more complex.

Wednesday, June 26, 2013 
Why Alpha Anywhere matters in today's mobile world [link]
I've been telling people that they should look at Alpha Anywhere, the product for creating mobile apps from the company that I recently joined as CTO. I often hear back "What about 'something else'? How is Alpha Anywhere different than what we have? I don't see why I should care."

Based on such discussions, I've written a short essay and created a few companion videos to answer that question in a way that has helped others see why Alpha Anywhere matters.

Read "Why Alpha Anywhere matters" in the Writings section of my web site.

Alpha Anywhere logo

Some key points:

There are lots of "domain experts" who write custom applications for businesses in Excel/VBA, Microsoft Access, and simple PHP/HTML. The people who produce these applications are not about to learn a few new languages and frameworks, and then write code line-by-line from scratch. There is a continuum of ways to author "programs", running from statement languages like C and Java, to dialog box-centric systems with one-click preview like Visual Basic, to direct manipulation systems like a word processor. The further you move down this continuum, the wider an audience of potential users. Alpha Anywhere is further down that continuum than other systems. It lets companies build for the mobile world with the developers they already have, yet still have the power to create the meaningful apps they need.

That's enough reason to check it out for either your own use or for recommending to others.

Monday, June 24, 2013 
Live streaming a town meeting is a good thing [link]
Last night I had an interesting experience that others might learn from.

I am a member of a group of a few hundred people a few decades old that is self-governing. We don't have any long-term leader or "official" head. For example, meetings are led by a "moderator" -- a volunteer post that gets passed to another person every couple of years. While lots of decisions get made by whichever individuals care most about the topic, for major, controversial things, we have a quarterly "town meeting" where a few dozen people or more show up and discuss and "vote".

Since not all of the members who care about a topic can make it to the meeting (many have young children or other responsibilities, are out of town, etc.) there has been a request that we look into some sort of "Internet solution". A few of us more techie members got together and worked out a plan. We'd use a simple streaming service (UStream.tv) on a password protected "channel". We would not have a back channel -- if you wanted to participate, you had to be there in person. We tested it out a few weeks ago to see if the WiFi and acoustics at the location where we hold the meetings worked and tweaked things.

Here is what we learned last night at the first real use of this technology:

First, the explicit technology: For video, I used an old, home video camera with Firewire output (Canon HV30) and external sound input. It was on a tripod and using it rather than a webcam let me zoom in on the person speaking if necessary, as well as pan around the room. (The room was a large classroom, with tables set in a large rectangle so the 30 or so of us could all sit like a big circle.) For sound, I had a handheld wireless mike (Shure PGX) connected to a mixer (Behringer 802) as well as a shotgun mike on the same mixer (for the few times when people weren't using the handheld). The output of the mixer went into the external input of the camera. The camera was connected to an old MacBook Pro through Firewire. I ran UStream's software (installed -- not the web version) for streaming to WiFi. I found that it worked best when the camera signal was SD and not HD (better frame rate, and the lower resolution image was not a problem if the sound was good). It also works best if no other applications are running (like browsers with lots of tabs open...).

Reports from the field: When the handheld mike was used by someone speaking, the sound quality was quite good and very much acceptable. When things caused dropouts (such as when I had neglected to kill a browser window) that was bothersome but it was still good enough. Using the "free" UStream service, with occasional ads breaking up the stream, was OK. Perhaps we'll pay for ad-free next time if more people sign up.

Was it effective? Yes! Here's how we know: People listening were very much engrossed in the content. A common request was for a back channel so that they could participate (we had decided in advance not to allow this to encourage people to show up -- we didn't want everybody to stay at home and just flame away on email). One person emailed during the meeting asking if they could add their two-cents.

The biggest clue that it was effective? One person who was not there received a text from his spouse telling him about it and pointing to the stream URL. He found the topic, as he watched it on screen at home, so interesting that he hopped into his car and joined the meeting in person so that he could say his piece. That was a big surprise and a very concrete form of usability testing.

The psychological take-away many people noticed: The handheld mike was a big win. The mike was not connected to a speaker system and had no electronic effect as seen by people in the room. However, we switched from trying to use the shotgun mike (which picked up lots of air-conditioning room noise but didn't require anything on the part of participants) to asking people to use the handheld.

At first, one person carried the mike from participant to participant as discussion progressed. Very quickly, people started passing it around themselves instead. Then the magic happened: People stopped calling out and just motioned for the mike, which was dutifully passed around. As it passed around, people spoke in turns. If someone, as they were passing it, had been unsure if they wanted to speak, having the mike in-hand pushed them over the edge to speak. This was great! People who may have been a little shy to fight for the floor were given equal status and became more likely to participate. Having the "token" of the mike also seemed to cut down on side conversations and interruptions. I hope that knowing that a friend of theirs was listening (confirmed by the person who showed up) made them more accepting of the mike, too. The auto-gain of the camera sound handling meant that as long as the mike was somewhat near them the sound was good -- no need to have an exact position or correct them.

I found all this interesting and thought some of you might, too. Live streaming of meetings, even for noncommercial groups with little money, is becoming more and more common, so I thought the details here, besides to remind me for next time, would help others.

Wednesday, June 19, 2013 
A big change in what I'm doing [link]
I've recently joined Burlington, Massachusetts, based Alpha Software Corporation as their CTO. After three and a half years of doing iOS programming on my own, and after tracking the reception of mobile and touch-enabled devices in the enterprise, I feel the time is right to take on an exciting new challenge.

I've written up what led me to this change. Please read "Joining Alpha Software as CTO".

Along with announcing that I'm working with them, Alpha made a few other announcements today.

One is that two other "old-timers" are actively advising them: Joseph Alsop and John Cullinane. They each founded and grew a very successful enterprise software business to over $1B in valuation. Joe was CEO of Progress Software, a global supplier of application infrastructure software. He is now on Alpha's board. John headed Cullinane Corporation (later renamed Cullinet), the "first successful software products company" -- they were the first software company to successfully go public, ever.

The reason we are all involved is the new product that Alpha is announcing today: Alpha Anywhere. It is the "first complete environment to rapidly build and deploy business applications for mobile devices and personal computers."

My "Joining Alpha" essay explains what it is about Alpha Anywhere that I find special. Watching the videos on the "Learn More" products page of the Alpha Software web site is the best way to find out what Alpha Anywhere is technically. I was heavily involved in the videos on that page. One reason I did that is to help my readers here understand what it is. If you watch the videos, you'll see my hands (literally) in many places, and sometimes hear my voice and see my face, too.

Here's a picture of me along with co-founders Richard and Selwyn Rabins, CEO and President of Alpha Software in Richard's office a few months ago:

Me along with Selwyn and Richard Rabins
What about Note Taker HD? I'm still actively selling it and doing customer support. See the "Joining Alpha" essay for more information.
Archive   Home   Newer   Older
© Copyright 1999-2018 by Daniel Bricklin
All Rights Reserved.

See disclaimer on home page.