Entries Tagged as 'Technology'

Two Thoughts On Today's Adobe MAX (2011) Day One Keynote

Adobe , Miscellaneous , Technology 2 Comments »

I'm not going to try and summarize the keynote:  you can either watch the replay at http://www.max.adobe.com/online/ or read a brief synopsis at http://max.adobe.com/news/2011/keynote_day1.html.

My first thought is actually about some news that wasn't part of the keynote, but was announced on the Internet during the keynote:  Adobe's acquisition of PhoneGapPhoneGap is an application framework that allows developers to build mobile apps using web technologies (HTML, CSS, and Javascript) and the PhoneGap API (to access particular device functions like geolocation, the camera, internal storage, etc) and then package and deploy those apps such that they work on most mobile operating systems (Android, IOS, Blackberry, and a few others).

What struck me about that news was that it means Adobe now provides two ways for app developers to develop cross-platform apps.  If a developer is already familiar with Flash and Flex development, they can build mobile apps using Flash Builder and Adobe AIR.  If the developer is more skilled with web design and programming, they can build apps using PhoneGap.  In both cases, the end result is an app that runs natively on your device of choice (IOS, Android, whatever).

First of all, it's yet another example of Adobe's willingness to support both Flash and HTML5 as development platforms going forward.  A number of tech analysts contend that Adobe's development of new tools that play nice with HTML5 is a capitulation of some kind to the way the industry is moving.  I don't see it that way: Adobe may be synonymous with Flash, but it's never been all about Flash with them.  They have always supplied the tools that the digital and web creation markets have demanded, just as any sane company would, regardless of what their internal preferences might be.

The other thing about the PhoneGap acquisition is that it will expand the number of developers using Adobe tools and technologies to create mobile apps for both Android and IOS.  And now suddenly Adobe potentially a big player in the smartphone and tablet space, not by release their own mobile OS or mobile hardware, but by providing the tools to any developer who wants to write on any and all of these platforms.  To be clear, at the moment there are certain kinds of apps or app functions that a developer would want or need to develop in native OS code, but as the Adobe tools provide ways to overcome those limitations (such as the ability to include native code extensions in Flash/AIR apps), the number of reasons for writing an app in native OS code (and hence writing a second version for deployment on another platform) are going to become fewer and fewer.

My second observation regarding the keynote concerns the suite of touch-optimized mobile apps - the Adobe Touch Apps - coming in November to Android devices and later to IOS devices.  While some of the apps are geared more towards visual designers, the Proto wireframing app is something I could use in the design phase of my web and mobile application work, and, well, who wouldn't want a touch-optimized version of Photoshop to use to mess around with their photos?

And that's when the thought occurred to me:  here were some apps that I could use to be productive with a tablet.  I'm an application developer who writes code.  I have access to two tablets and I don't use either of them to write code or generate digital content of any kind.  For me, tablets have always been digital consumption devices (something Amazon seems to recognize with their new Kindle Fire tablet) for viewing video, looking at pictures, or reading web pages or books, and kinda superfluous given I can do all that and much more with a laptop (to be clear, I do love my Nook Color as an e-reader, but I rarely use it to surf the web or anything else).

But the apps Adobe showed off today made me feel like I would in fact want to use them on a tablet, because they were designed specifically with tablets and touch-interaction in mind, not as desktop apps shrunk into a mobile form factor.  That to me is a step in the right direction, and it's apps like those that are going to grow the tablet market by making the tablet experience more compelling.

An Overview of buzztouch, A Mobile App CMS for Non-Programmers

Miscellaneous , Mobile devices , Technology 3 Comments »

The other day I stumbled on a Make Use Of article about buzztouch, a "iPhone, iPad, Android app builder and content management system."  Since we're researching options for creating cross-platform mobile applications, and the article indictated that it was worth checking out, I decided to sign up and give buzztouch a spin.

buzztouch is designed to let non-programmers build a mobile app on the buzztouch website using a collection of web-based forms.  The app-building interface prompts you to create certain items, like a launcher icon for the app, a banner image for the home screen, and an "info" page for the app, but you choose what other content you wish to provide from a drop-down list of different components.  One component lets you create a screen of formatted text using CKEditor, while another lets you create an app screen using HTML, CSS, and Javascript.  There are components for pulling in remote content such as web pages, YouTube pages, streaming audio and video files, and RSS feeds.  One component lets you pinpoint one or more locations on a Google Map with brief location information that a user of the app can then use to get driving directions to those locations from their current position.  Even though I was casually playing with the system, I was able to create an app using several of these components in under two hours.

Once you've created the app, you can then download the native source code for the app:  you're provided with separated source code downloads for IOS and for Android.  The source code comes in a .zip file, which also contains a readme file with instructions on how to compile the source code for that particular platform and create the native app.  It only took me a few minutes to create an Android app from the source code, and it only took me that long because I had to provide a Google Maps API key to enable the mapping component I'd added (the readme provided exact instructions on the changes I need to make it the code to use the key).  I had my IOS developer colleague compile the IOS version of the app, and it was also smooth sailing for him.  The resulting app on the Android platform looked a little rough simply because of the generic design elements, but the IOS version looked pitch-perfect.

The first time you access any component or screen in the mobile app, there is a pause as the app retrieves the content or content instructions from buzztouch then caches it for local use.  This is where the content management system aspect of buzztouch kicks in:  any changes you make to the app on the buzztouch site get pushed to (or pulled by, not sure which) the mobile app.  So the app owner doesn't need to recompile and update the app through the App Store or the Android Market in order to make content changes.  If the mobile device doesn't have a network connection, then the cached content is used.

So what's my overall take on buzztouch?  I think that if you need to build a mostly informational mobile app, something that serves the same purpose as a mobile-optimized website, then buzztouch is a compelling option because of how easy it is to create the app and then update the content.  Even if your long-term strategy is to redesign an existing "desktop"-optimized website to be mobile-friendly as well, a buzztouch app could fill the void until that goal was reached.

If you need to build a mobile app that's more interactive, one where the user can send and receive custom data, then buzztouch is at best an incomplete solution.  There are no buzztouch components for collecting data (though the app itself will capture GPS info from the device in order to map where the app has been used, which is both useful and slightly disturbing), but you could probably use the Custom HTML component to create a web form that transmitted data via a regular form submit or via AJAX.  And there are as yet no components that let you access device-specific functions like the camera or accelerometer.

On the other hand, if you are capable of doing some IOS or Android coding, the native code provided by buzztouch could serve as a starting point for adding additional functionality:  the buzztouch folks seem to be open to folks using the generated code to advance their learning of native app programming.

So overall, I'm impressed with what buzztouch has done so far with the direction they've taken, and I hope they continue to improve on the platform.

Planning a Day at the DC Auto Show

Miscellaneous , Technology 1 Comment »

The big annual auto show is in downtown Washington D.C. this week, and I'm planning on attending this coming Saturday (Feb. 5).  Even though I'm not looking to buy a new car anytime soon, my current car is twelve years old, and if it should suddenly die on me this year, I'd like to have some idea of what kind of car I might get to replace it.  Plus, I want to check out some of the new tech that's been appearing in cars the last few years.

I'm blogging about this because it occurred to me that maybe I could do some automotive scouting for other folks as well.  Have an interest in a particular car or car technology but don't have a local auto show you can attend?  Tell me what you're interested in by leaving a comment, and I'll look for it at the auto show and give you any info or impressions that I get.

And hey, if there are any local DC/MD/VA folks who'd like to meet up and maybe hang out at the show that day, that would be cool too.  :)

My Quick Reaction to Steve Jobs' "Thoughts on Flash" Letter

Adobe , Miscellaneous , Technology 7 Comments »

So just when I thought that all of the rhetoric regarding the Apple verses Adobe dustup over Flash had died down, Steve Jobs published an open letter entitled "Thoughts on Flash" on the Apple website today, ringing in yet another round in this boxing match.

I encourage those folks who care about this issue to read the letter in its entirety (rather than someone's summary of it).

Some quick thoughts I have on what was said (just my opinions/observations):

  • When Jobs dings Adobe on the issue of Flash being proprietary, he acknowledges that Apple has proprietary products as well, but that "we strongly believe all standards pertaining to the web should be open." Why, exactly? What makes it okay to engage in proprietary protections off of the web but not on it?
  • Jobs makes the point of mentioning WebKit to illustrate that Apple contributes to the open standards for the web.  He fails to mention that Adobe also makes contributions to web standards as well (the partnership with Mozilla on Javascript engine code comes to me) and that Adobe does have products in their toolset to allow developers to create websites using the latest advances in HTML, CSS, and Javascript. Adobe certainly has an interest in promoting Flash, but they continue to support other competing technologies.
  • It's interesting that Jobs implies that Adobe was tardying in providing support for the H.264 hardward decoder, yet it has been pointed out by a number of sources that Flash has long suffered from performance issues on Macintosh computers because Flash was not allowed to make use of the graphics accelerator on Macintosh chips.
  • Jobs states that any Flash sites that rely on "rollover" events to activate certain functionality would have to be re-coded in order to work on the iDevices. That may be true in some cases, but let's not forget that certain HTML and Javascript events also rely on the idea of hovering over a page element with a mouse, or dragging and dropping an item. The need to adjust to a multi-touch paradigm is not something that just affects Flash-based sites; it affects websites built with those open web standards as well. And just because something doesn't work quite right on a new device doesn't mean you should throw it out and start over from scratch.
  • I see the issue of allowing Flash to run as a browser plugin on the iDevices and the issue of letting Adobe provide a tool for developers to translate Flash code into a binary file that runs on the iPhone OS as two separate things, yet the way the letter is written it seems to combine the two issues. Perhaps it was done as a means of using the earlier arguments to sway some options regarding the Flash-to-iPhone compiler issue.
  • A lot of these complaints Jobs has regarding Flash (valid or not) can be or are being rectified. Instead of encouraging Adobe to address the things he has issues with, he "suggests" Adobe should drop Flash and stop criticizing Apple. That certainly implies to me that even an open, secure, battery-friendly, and efficient version of Flash would still never be allowed on the iDevices.
  • I have to wonder what he thinks this letter will accomplish. The fact that he wrote it at all seems to imply either some desperation or annoyance over the fact that that Apple's anti-Flash stance hasn't been as widely accepted amongst the industry and amongst consumers as he'd like.  Perhaps he's looking to gain a few more converts to his stance at the cost of making his opposition that much angrier with him?

E-readers: No One Has All the Answers Yet

Miscellaneous , Technology 3 Comments »

Today I attended a presentation about a joint study being conducted between the English and Computer Science departments at the University of Maryland regarding the use of e-readers for academic reading. What was interesting about the study was that it wasn't just about whether students preferred using an e-reader device over standard textbooks, but whether the simultaneous use of TWO e-reader devices was more conducive to academic reading.

On the surface, using two devices to read instead of one seems a bit odd, but the premise of the study was based on research that showed that individuals engaged in academic reading (reading to learn, to synthesize information and translate into research notes) often had two or more sets of reading material (books, research papers, etc.) in front of them, and that they would go back and forth between those sources as they took their notes.

So at the beginning of the semester, the students in this literature course (which appropriately is a course that studies the history and future direction of books) were each given one of these e-reader devices developed by the Computer Science department. Each of these e-readers were about 7"x10", used E-ink for the display, allowed students to write notes with a stylus, and were optimized for quick page refreshes and overall book navigation. Now that the students have had a few weeks to acclimate to the use of the readers, they are each going to get a second one and try using them simultaneously. Although the presenter didn't go into great detail, the e-readers apparently have the ability to transfer and synchronize data with each other, so the students can decide to tackle the same source material with both devices or perhaps create references between two different documents.

To me, studies like these really highlight the fact that the e-reader market is still a young market and that no one has all the answers. Mainstream e-readers like the Kindle, the Nook, and the almost-here iPad may lead the e-reader market when it comes to casual reading, but there hasn't been as much of a focus on what works when it comes to e-readers for academic or professional use. As was discussed after the presentation, there may be a shift in the very concept of a "book" is as people explore not only different ways of consuming text-based content, but ways of producing and presenting the content, perhaps with the addition of other types of media.

It'll be interesting to see what comes out of all of this several years down the road.