Contents of RSS feed for:

Dan Bricklin's Log
VisiCalc co-creator Dan Bricklin chronicles his life in the computer world with pictures, text, and commentary.
BCS Mac Introduction Meeting video is now available -- how that came about
The January 30, 1984, video of the introduction of the Macintosh to the public at a Boston Computer Society General Meeting is now available online. Harry McCracken, an editor at large at TIME for personal technology, posted an exclusive look at the video early this morning, right after excerpts where shown at the Mac 30th event in California (an "official" event marking the 30th anniversary of the original Mac announcement at the same place where it occurred). The Computer History Museum will be posting material on its web site tomorrow, and will update the video when additional processing of it finishes.

See "Exclusive: Watch Steve Jobs’ First Demonstration of the Mac for the Public, Unseen Since 1984" on

Harry explains how there were other videos of prior deliveries of Steve Job's talk introducing the Mac, but that this one is special for several reasons, some of which I have touched upon in my blog post Friday about it, such as the Q&A with a general tech audience. He also explains a bit about how the release of the video came about. Let me fill in a bit more.

These were not fully "lost" videos. I have had my copy of the January 1984 VHS tape for years and let others know I had it, showing excepts sometimes when I gave talks. Given the use of Apple material, and the special nature of the video, I did not feel it was time to release it yet to the public as I was slowly doing with other videos I have (not BCS ones). I was in contact with the videographer, Glenn Koenig, who shot most of the BCS meetings on Software Arts' behalf over the years. He let me know that he had masters of many of them, though he hadn't cataloged them (and didn't search out the Jobs one until Harry asked, which yielded better versions of parts of the presentation). I let him know of the material that I had made sure made it to the Computer History Museum. I encouraged him to continue to maintain his tapes in good condition, which is what he has been doing all these years.

We always intended to complete the edits of this material, but there is a lot of it, and digitizing it properly and editing it takes a lot of time and money. We didn't have the funds to do that and it was unclear if others would chip in and how to bring that about. Doing the work prematurely with the wrong equipment could compromise the tapes. (Of course, waiting too long could cause them to deteriorate too much.)

When Harry, a BCS member going back to the VisiCalc days, contacted BCS founder Jonathan Rotenberg in the fall of 2012 to ask about video from BCS meetings, Jonathan got him in contact with Glenn. Glenn, Jonathan, and I brainstormed about ways to finally make the restoration and release happen. I contacted Ray Ozzie, who I knew was interested in historic videos and had worked with us at Software Arts in the early 1980's. He, like Harry, suggested the Computer History Museum as a means for funding instead of something like Kickstarter. I have been a long-time supporter of the Museum, and have been inducted as one of their "fellows" for my work on VisiCalc, and knew this was the right way to go.

Eventually, Jonathan, Glenn, and I started working with people at the Museum, cataloging which material we had between us, and worked up a budget and a plan for fundraising. Glenn pointed out the upcoming 30th anniversary of the Mac as a good "news hook" and that a hoped-for article by TIME could help publicize the entire set (thank-you, Harry, for coming through with a great one!). We met periodically on the phone (we all had other jobs to keep us very busy) and eventually crafted a "request" letter and a list of potential donors. Glenn produced a short trailer of excerpts from a few of the tapes using some refurbished equipment to show those people.

In September of last year we had the material ready for fundraising and I hand-signed (and in some cases added a little note to) a few dozen letters and mailed them out. Within a little while some money trickled in. Then, Brad Feld, a friend from the early Trellix days now living in Colorado, contacted me for more information. Within a few days he and his wife Amy became the major funders, ensuring that the project was well off the ground. He also helped us by reaching out to some of the people I had approached, too. We have since raised enough to do this project well, and hopefully even do additional tapes that are surfacing, though the Museum could always use additional funds for such things.

The people producing the video for the Mac 30th event, most importantly Gabreal Franklin, helped Glenn work out details and ensured that there would be quality video for their event, both from the January 1984 video and some other.

For many reasons, including the difficulty in getting the slides shown the way we need them, the current version of the Mac Introduction is just a "rough cut". There is more editing that will occur. In any case, Glenn did many late nights to make this happen on time.

Now that everything is set up, we will be processing other videos, too, and release them in batches. I'll write more about them when they are available. To me, some are of them are of the same historic value as this one, if not more.

The Mac Introduction video has served its purpose well. It has drawn attention to the Boston Computer Society and the other videos, and to the Museum. It has helped a new generation see what happened in the early days of the PC revolution, and an older generation remember their past, and helped chronicle the thinking of the time for posterity. It has also helped fill in the record of the life of a giant of our industry, capturing an interaction with the users of his works like no other.
Published: Sun, 26 Jan 2014 20:55:46 GMT
The Mac turns 30 and because we preserved the history you will be able to relive it
Today is 30 years since the Apple Macintosh was announced. That event occurred at a shareholders meeting in California. The following Monday, Steve Jobs and a crew of people from Apple traveled to Boston, Massachusetts, to redo that event for the public. It was at the Boston Computer Society General Meeting on January 30, 1984, at the John Hancock Hall in Boston.

In addition to Steve's speech and demonstration, he also brought many of the developers of the Mac software and hardware with him. After his presentation, they all sat on stage and answered questions from the audience and did further demos. For the over 1,000 people who attended, it was an amazing event. At the shareholders meeting there was the worry of how it would be received and if the demos would work. At the BCS meeting there was much less pressure and Steve was relaxed and confident and engaged the audience. The attendees were knowledgeable and savvy.

There is something else about the Boston event: My old company, Software Arts, at my suggestion as I recall, was paying to have video tapes made of many of the BCS General Meetings. (I was a board member of the BCS at various points). For this event, Apple provided additional cameras and made sure the lighting was good (it was not good in California, apparently).

We at Software Arts ended up with an edited VHS copy of the event that I have kept for these 30 years and sometimes show excerpts from when I talk to students to show them what it was like in the "old" days. I also would show it to my daughters to let them see how a real pro delivered a speech. At this point I know Steve's intonation on every syllable of the start of his presentation. (It's different than when he gave it in California.)

What happened last year is something wonderful: It turns out that many of the original BCS meeting tapes still exist. Some were donated to the Computer History Museum with my help. Many of the master tapes were still with the videographer, Glenn Koenig, including 3/4" tapes that are higher quality than the VHS copies. Together with Glenn and Jonathan Rotenberg (the founder and initial head of the BCS), we finally started a project with the Computer History Museum to restore the tapes and make the videos available to the public. This involves careful work on refurbished old equipment and careful editing remembering the events themselves to get the best possible video and sound. It will also include transcripts and other related museum-type treatments.

We have raised money to pay for this (there are over 20 meetings to process) and have started digitizing and editing the tapes. The Mac Introduction will be the first, but there are others of great interest with the leaders of many leading personal computing companies, from Microsoft to Radio Shack to Digital Research to Lotus and IBM.

A thank you to Brad Feld, who remembers the impact the BCS had on his interest in both technology and entrepreneurship from his days at MIT, and all of the others who came through with the money we needed!

The Mac video will be released soon (I'll post here when it's available) and others will follow over time.

[Photo of Steve Jobs about to insert disk into Mac in January 1984, from my VHS copy appears here in the original blog post on Dan Bricklin's Log]

For those of you who have only seen the young Steve Jobs portrayed by actors, seeing him and his team as they actually were should be a real treat. I get chills down my spine watching it.

It is such a joy to realize that a decision we made over 30 years ago at my old company, when the personal computing industry was a young oddity, will bring those days to life for a new generation and for generations to come and that they will care and appreciate it.

(This isn't the first time I've felt that way. Another recording we did, an internal one of a staff meeting as the IBM PC was being announced, ended up a key scene in the PBS documentary "Triumph of the Nerds" -- see "IBM PC Announcement" on my web site's Writings section. I've also posted a few other old videos I have: See "Video of Fall Comdex 1983" and "Video of Bob Frankston's tour of the WWW in 1994".)

I recorded a 20-minute podcast interview with Jonathan yesterday to get the back story on how he, a 20-year-old at the time, got Steve Jobs to debut in Boston. You can listen to the MP3 recording of our Skype conversation, "Jonathan Rotenberg about the 1984 BCS Mac event 2014-01-22" on my podcast channel.

In those days, the top companies in the industry would come to the BCS and other user groups to demonstrate their new innovations, sometimes as their first public showing. (The BCS was the most influential and probably biggest such group.) Local and national TV didn't show up to document the events (though the Wall Street Journal and other press often did). However, "personal" video taping helped preserve some of it. I know that other user groups did taping (I have some tape of me at a least one of those venues) and I hope that other material has been preserved and will be made available to the public and to historians through the Museum and other means.
Published: Fri, 24 Jan 2014 19:44:48 GMT
MassTLC unConference session on Responsive App Design
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,, 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 [] 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
-- Grid on iOS
-- Runkeeper
-- Messaging apps (Apple: context changing UX)
-- Tandem Seven (design firm HQ in Massachusetts)
-- 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.
Published: Fri, 08 Nov 2013 20:04:01 GMT
Responsive App Layout
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 embedded on original blog post on]

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.
Published: Thu, 17 Oct 2013 16:13:18 GMT
What Jeff Bezos and John Henry should read to prepare for their new ownership
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 web site.) How will they guide their acquisitions as technology evolves? (Jeff brought us 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 and tweets as @ProfDaly.
Published: Tue, 20 Aug 2013 01:56:47 GMT
More about web app speed
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.
Published: Fri, 26 Jul 2013 21:59:41 GMT
Are mobile web apps really slow?
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.
Published: Thu, 11 Jul 2013 16:35:20 GMT
What's holding back HTML5 from mobile dominance?
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.
Published: Mon, 01 Jul 2013 15:32:00 GMT
What it looked like to surf the web in 1994
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.
Published: Sun, 30 Jun 2013 01:03:46 GMT
Mobile device feature war
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.
Published: Thu, 27 Jun 2013 16:58:20 GMT
Updated: Sun, 26 Jan 2014 20:55:57 GMT
The URL to provide to an RSS aggregator when subscribing to this feed:
(For more information about RSS see: What is RSS?.)