Skip to content →

Tag: Chrome OS

A Month with the Chromebook Pixel

Last month, I had the pleasure of attending Google I/O – Google’s annual developer conference and product geekfest. To put it simply, it was probably the nerdiest conference I’ve been to (and yours truly has been to some really nerdy conferences) with Google Glass users everywhere and flying, internet-controlled, camera-connected dirigible floating above the conference floor among the attractions.

One of the things that Google tried to emphasize to I/O attendees was the growing idea of Chrome, Google’s web browser, as a key platform for developers to embrace. Part of that message, of course, came from the talks and sessions where Google promoted Chrome’s widespread adoption (if you count mobile deployments, Google claims 750 million users worldwide) and proudly touted Chrome’s support of both sophisticated open technologies like HTML5, WebRTC, and WebGL, as well as proprietary-to-Chrome technologies like Native Client and their new Packaged Apps capability.

Equally (or perhaps more) effective was the conference’s giveaway of its Chromebook Pixel (not to mention some pretty interesting artistic displays showing off the device and its capabilities, see below).

My generally positive take on the Pixel’s predecessor Samsung’s Series 5 Chromebook is one of the more popular posts on this blog and so I thought I would share my take on Google’s latest and greatest. In a nutshell, I will say that the Chromebook Pixel is light years ahead of its predecessors and is an amazing device which hints at the potential of well-built Chrome OS hardware, albeit one which is probably not worth the $1200+ price tag:

    • Good, not good enough, performance: While the Series 5 routinely stumbled and hiccuped, the dual-core Ivy Bridge processor in the Pixel, while not the fastest chip around, was up to the task of almost any large web workload I threw at it – multiple tabs with Netflix and complex webapps like Tweetdeck and Gmail and Feedly running. Even Evernote, which I had not been able to get working on the older Chromebook, worked without any problems on the Pixel.
    • Amazing display: In the same way that other remarkably high resolution displays make you want to view more content (Nexus 10, Retina Display Macbook Pros), the Pixel has actually managed to steal web browsing and video watching time from my tablets, something I didn’t expect would happen.
    • Touch: I used to be a big skeptic of the importance of touchscreen displays on laptop form factors – no more. As cheesy as it sounds, the type of relationship you have with content is different when you can use touch gestures to zoom in/out and scroll up/down versus using arrow keys or a mouse. I can’t say that I primarily use the touchscreen in navigation, but it’s a nice touch (pun intended).
    • Much better industrial design: I don’t claim to be an ID expert, but the attention to detail on the machine is decidedly impressive for a company that many in the tech industry for years felt just didn’t care about design quality. The touchpad beats most of what the PC industry has put out in feel and responsiveness (although that’s a low bar to beat) and, taking a page from Apple’s playbook, supports multi-finger gestures. The device body is smooth aluminum with only a groove on the body for cool-looking LED lights to come out as a signal that the device is on and an interesting piano hinge for the display which someone engineered to function not only as a hinge but as a heat sink and Wi-Fi antenna. Simply put: it doesn’t feel or look cheap.

Couple that with the advantages I described to all Chrome OS systems (rapid boot, easy multi-user support, frequent and automatic updates, syncing tabs/histories/passwords with all your other Chrome browsers), and I think you have a fairly compelling device.

That said, three major problems are worth calling attention towards:

    • This is still just a browser: granted, most of what we do today is in or can easily be replaced by web-based applications of some form or the other, but, this won’t be playing Starcraft or running Excel or operating a server or doing software build work.
    • Underwhelming Battery life: for an operating system that is effectively a browser, I am surprised that my typical battery life is somewhere in the 3-4 hour range, and significantly lower if I’m using Netflix or YouTube. I can’t tell if this is simply an issue where Google included too small of a battery to save costs, if this is the energy from the extra processing power and backlight needed to run such a high-resolution screen, or if this is a operating system/firmware bug where the video codecs aren’t being used properly, but this is something that will likely need real improvement.
    • Extremely high price: while this is a fantastic device, its usage limitations (to basically being a big browser) and storage and memory and battery life limitations don’t make this a $1200+ machine. Interestingly, I do feel that if they included a dual-boot to Linux option, the screen and industrial design could very well justify a higher price (compare with Linux laptop vendor System76’s new Galago UltraPro)

So, the verdict? I am extremely happy I got this device for free from Google. It’s something I use regularly because it is a delight to use and really does put forward Chrome in a fantastic light for developers (which is really the purpose of the giveaway at Google I/O). This device is also probably more than enough for what the average computer user needs (who is mainly interested in checking email, reading articles, watching videos, and playing webgames) and has unique advantages for enterprise/educational settings. But, the fact that Chrome OS still can’t do everything that I need it to do and has limitations in battery life and storage and memory make it difficult to justify the high price for a regular consumer purchase.

Any other Chromebook Pixel users out there care to share their perspectives?

Leave a Comment

A Few Months with the Chromebook

(Hello visitors, if you’re interested in this post, you may be interested to know that I have posted my impressions of the newer Chromebook Pixel here)

Last year, I had the chance to attend the New Game conference sponsored by Google to talk about the use of HTML5 in games. The conference itself was fascinating as it brought up many of the themes I’ve mentioned before on this blog about the rise of HTML5 as a tool to build compelling software, but one of the highlights was that Google gave every attendee a free Samsung Series 5 Chromebook to test out and use for development purposes.

chromebooks-portability

I’ve blogged a few times before about Chromebooks and how they represent the next logical step in Google’s belief in the web as the core platform for software delivery (seeing how they’re machines that are built almost entirely around the browser), and I jumped at the chance to test it out.

I initially tested out the Chromebook shortly after getting it for a week or two. To be completely honest, I was underwhelmed. While there were many cool things about the operating system (it always being up to date, the built in Google Talk experience, and the ability to use Google Docs as a scratchpad for starters), the machine just felt very slow (likely in part because of the low-end Intel Atom processor inside). The device never seemed to sync properly with my Google account, the lack of a desktop made this feel more like a browser with a keyboard than an operating system, and poor support for offline functionality and handling of peripherals made it feel very constraining. I meant to write up a review on the blog but I never got around to it and it faded from memory, collecting dust in storage…

Flash forward to May when Google unveiled a pretty bold re-vamp of the Chrome OS operating system that lies behind the Chromebook: Aura. Aura replaced what was formerly a within-one-browser-window experience with something which looks and feels a lot more like a traditional operating system with a taskbar, multiple windows (and hence true multi-tasking), a desktop background, a “system tray/control panel” to readily access system-wide settings (i.e. battery life, which WiFi network I’m connected to, screen brightness, etc), and an application launcher. My previous problems with syncing with my Google account are gone (and its support for tab syncing – where I can continue browsing a webpage I was reading on another device – make using this very natural). The experience also just feels faster – both the act of browsing as well as thinsg like how quickly the touchpad responds to commands. Chromebooks now also handle more file types natively (whether downloaded or from removable media), and, with the recently announced offline Google Drive integration, Chromebooks have gotten a lot more useful and have taken another step to achieve the “web file system” vision I blogged about before.

Much to my surprise, I’ve even found myself turning to my Chromebook regularly as a casual consumption device. It being instant-on, browser-centric, and ready support for multiple user accounts makes it a perfect device to watch TV epsiodes or movies from Google Play, Netflix, or Amazon Videos or to share interesting articles to my Tumblr (something that my touch-centric Galaxy Nexus and Motorola Xoom do less well at).

Realistically, there are a set of apps which I’ve found to work much better on Windows/Linux (mainly coding, using Microsoft Excel, and composing blog posts) and which prevent me from using a Chromebook for 100% of my computing needs. But, while important, these only take up a minority of my time on a computer — what actually stops me from using the Chromebook much more actively as a primary machine in my job and day-to-day are two far more pressing items:

  1. Evernote does not work. I am a very active user of Evernote for note-taking and note organization, and its unfailing ability to crash whatever tab is open to it on a Chromebook is a pretty major roadblock for me.
  2. Some web apps don’t play nice because they don’t recognize Chrome OS properly. The key culprit here for me is Microsoft Outlook. A conspiracy theorist might think this was some ploy by Microsoft to get people using Chrome OS to switch to Windows or by Google to get Outlook users to switch to Google Apps – but at the end of the day, Microsoft’s very nice, new Outlook Web App, which works beautifully on Chrome on my Windows 7 machine, treats the Chromebook as if it were a barely functioning computer running Internet Explorer 6 – leaving me with a crippled web experience for what is my corporate email lifeline. If Google made it possible to spoof the browser identification or found a way to convince Microsoft to give Chrome OS flying colors when it comes to serving up web apps, that would make me a MUCH happier camper.

These issues aside, there is no doubt in my mind that Chrome OS/Chromebooks are a concept worthy of consideration for people who are thinking about buying a new computer for themselves or their loved ones: if you spend most of your time on the computer on the web and don’t need to code or create/consume massive files, these machines are perfect (they boot fast, they update themselves, and they are built with the web in mind). I think this sort of model also will probably work quite well in quite a few enterprise/educational settings, given how easy they are to support and to share between multiple users. This feels to me like an increasingly real validation of my hypothesis of the web as software platform and, while there’s quite a few remaining rough spots, I was very impressed by the new Aura revision and look forward to more refreshes coming out from the Chrome team and more time with my Chromebook :-).

(Image credit – Chromebook – Google)

7 Comments

Why Comparing Google Drive to Dropbox is Missing the Point

Last week, Google unveiled its long-rumored Google Drive product with great fanfare. While the gaggle of tech journalists/bloggers issued predictable comparisons of Google’s new service with online storage/syncing services like Dropbox, I couldn’t help but think that most of the coverage missed the point on why Google Drive was interesting. Yes, its another consumer-facing cloud storage service – but the really interesting aspect of it is not whether or not it’ll “kill Dropbox/Box.net/iCloud/[insert your favorite consumer cloud service here]”, but the fact that this could be the beginning of a true web “file system”.

I’ve blogged before about the strengths of the web as a software development platform and the extent to which web apps are now practically the same thing as the apps that we run on our computers and phones. But, frankly, one of the biggest things holding back the vision of the web as a full-fledged “operating system” is the lack of a web-centric “file system”. I use the quotes because I’m not referring to the underlying NTFS/ExtX/HFS/etc technology that most people think of when they hear “file system”: I’m referring to basic functionalities that we expect in our operating systems and file systems:

  • a place to reliably create, read, and edit data
  • the ability to search through stored information based on metadata
  • a way to associate data with specific applications and services that can operate on them (i.e. opening Photoshop files in Adobe Photoshop, MP3s in iTunes, etc)
  • a way to let any application with the right permissions and capabilities to act on that data

Now, a skeptic might point out that the HTML5 specification actually has a lot of local storage/file handling capabilities and that services like Dropbox already provide some of this functionality in the form of APIs that third party apps and services can use – but in both cases, the emphasis is first and foremost on local storage – putting stuff onto or syncing with the storage on your physical machine. As long as that’s true, the web won’t be a fully functioning operating system. Web services will routinely have to rely on local storage (which, by the way, reduces the portability of these apps between different machines), and applications will have to be more silo’d as they each need to manage their own storage (whether its stored on their servers or stored locally on a physical device).

What a vision of the web as operating system needs is a cloud-first storage service (where files are meant to reside on the cloud and where local storage is secondary) which is searchable, editable, and supports file type associations and allows web apps and services to have direct access to that data without having to go through a local client device like a computer or a phone/tablet. And, I think we are beginning to see that with Google Drive.

  • The local interface is pretty kludgy: the folder is really just a bunch of bookmark links, emphasizing that this is a web-centric product first and foremost
  • It offers many useful operating system-like functionality (like search and revision history) directly on the web where the files are resident
  • Google Drive greatly emphasizes how files stored on it have associated viewers and can be accessed by a wide range of apps, including some by Google (i.e. attachments on Gmail, opening/editing on Google Docs, and sharing with Google+) and some by third parties like HelloFax, WeVideo, and LucidChart

Whether or not Google succeeds longer-term at turning Google Drive into a true cloud “file system” will depend greatly on their ability to continue to develop the product and manage the potential conflicts involved with providing storage to web application competitors, but suffice to say, I think we’re at what could be the dawn of the transition from web as a software platform to web as an operating system. This is why I feel the companies that should pay more close attention to this development aren’t necessarily the storage/sync providers like Dropbox and Box.net – at least not for now – but companies like Microsoft and Apple which have a very different vision of how the future of computing should look (much more local software/hardware-centric) and who might not be in as good a position if the web-centric view that Google embodies takes off (as I think and hope it will).

2 Comments

Chrome Remote Desktop

A few weeks ago, I blogged about how the web was becoming the most important and prominent application distribution platform and about Google’s efforts to embrace that direction with initiatives like ChromeOS (Google’s operating system which is designed only to run a browser/use the internet), Native Client, and the Chrome Web Store.

Obviously, for the foreseeable future, “traditional” native applications will continue to have significant advantages over web applications. As much of a “fandroid”/fan of Google as I am, I find it hard to see how I could use a Chromebook (a laptop running Google’s ChromeOS) over a real PC today because of my heavy use of apps like Excel or whenever I code.

However, you can do some pretty cool things with web applications/HTML5 which give you a sense of what can one day be possible. Case in point: enter Chrome Remote Desktop (HT: Google Operating System), a beta extension for Google Chrome which basically allows you to take control of another computer running Chrome a la remote desktop/VNC. While this capability is nothing new (Windows had “remote desktop” built in since, at latest, Windows XP, and there are numerous VNC/remote desktop clients), what is pretty astonishing is that this app is built entirely using web technologies – whereas traditional remote desktops use non-web based communications and native graphics to create the interface to the other computer, Chrome Remote Desktop is doing all the graphics in the browser and all the communications using either the WebSocket standard from HTML5 or Google Talk’s chat protocol! (see below as I use my personal computer to remote-control my work laptop where I am reading a PDF on microblogging in China and am also showing my desktop background image where the Jedi Android slashes up a Apple Death Star)

image

How well does it work? The control is quite good – my mouse/keyboard movements registered immediately on the other computer – but the on-screen graphics/drawing speed was quite poor (par for the course for most sophisticated graphics drawing apps in the browser and for a beta extension). The means of controlling another desktop, while easy to use (especially if you are inviting someone to take a look at your machine) is very clumsy for some applications (i.e. a certain someone who wants to leave his computer in the office and use VNC/remote desktop to access it only when he needs to).

So, will this replace VNC/remote desktop anytime soon? No (nor, does it seem, were they the first to think up something like this), but that’s not the point. The point, at least to me, is that the browser is picking up more and more sophisticated capabilities and, while it may take a few more versions/years before we can actually use this as a replacement for VNC/remote desktop, the fact that we can even be contemplating that at all tells you how far browser technology has come and why the browser as a platform for applications will grow increasingly compelling.

One Comment

Web vs native

imageWhen Steve Jobs first launched the iPhone in 2007, Apple’s perception of where the smartphone application market would move was in the direction of web applications. The reasons for this are obvious: people are familiar with how to build web pages and applications, and it simplifies application delivery.

Yet in under a year, Apple changed course, shifting the focus of iPhone development from web applications to building native applications custom-built (by definition) for the iPhone’s operating system and hardware. While I suspect part of the reason this was done was to lock-in developers, the main reason was certainly the inadequacy of available browser/web technology. While we can debate the former, the latter is just plain obvious. In 2007, the state of web development was relatively primitive relative to today. There was no credible HTML5 support. Javascript performance was paltry. There was no real way for web applications to access local resources/hardware capabilities. Simply put, it was probably too difficult for Apple to kludge together an application development platform based solely on open web technologies which would get the sort of performance and functionality Apple wanted.

But, that was four years ago, and web technology has come a long way. Combine that with the tech commentator-sphere’s obsession with hyping up a rivalry between “native vs HTML5 app development”, and it begs the question: will the future of application development be HTML5 applications or native?

There are a lot of “moving parts” in a question like this, but I believe the question itself is a red herring. Enhancements to browser performance and the new capabilities that HTML5 will bring like offline storage, a canvas for direct graphic manipulation, and tools to access the file system, mean, at least to this tech blogger, that “HTML5 applications” are not distinct from native applications at all, they are simply native applications that you access through the internet. Its not a different technology vector – it’s just a different form of delivery.

Critics of this idea may cite that the performance and interface capabilities of browser-based applications lag far behind those of “traditional” native applications, and thus they will always be distinct. And, as of today, they are correct. However, this discounts a few things:

  • Browser performance and browser-based application design are improving at a rapid rate, in no small part because of the combination of competition between different browsers and the fact that much of the code for these browsers is open source. There will probably always be a gap between browser-based apps and native, but I believe this gap will continue to narrow to the point where, for many applications, it simply won’t be a deal-breaker anymore.
  • History shows that cross-platform portability and ease of development can trump performance gaps. Once upon a time, all developers worth their salt coded in low level machine language. But this was a nightmare – it was difficult to do simple things like showing text on a screen, and the code written only worked on specific chips and operating systems and hardware configurations. I learned C which helped to abstract a lot of that away, and, keeping with the trend of moving towards more portability and abstraction, the mobile/web developers of today develop with tools (Python, Objective C, Ruby, Java, Javascript, etc) which make C look pretty low-level and hard to work with. Each level of abstraction adds a performance penalty, but that has hardly stopped developers from embracing them, and I feel the same will be true of “HTML5”.
  • Huge platform economic advantages. There are three huge advantages today to HTML5 development over “traditional native app development”. The first is the ability to have essentially the same application run across any device which supports a browser. Granted, there are performance and user experience issues with this approach, but when you’re a startup or even a corporate project with limited resources, being able to get wide distribution for earlier products is a huge advantage. The second is that HTML5 as a platform lacks the control/economic baggage that iOS and even Android have where distribution is controlled and “taxed” (30% to Apple/Google for an app download, 30% cut of digital goods purchases). I mean, what other reason does Amazon have to move its Kindle application off of the iOS native path and into HTML5 territory? The third is that web applications do not require the latest and greatest hardware to perform amazing feats. Because these apps are fundamentally browser-based, using the internet to connect to a server-based/cloud-based application allows even “dumb devices” to do amazing things by outsourcing some of that work to another system. The combination of these three makes it easier to build new applications and services and make money off of them – which will ultimately lead to more and better applications and services for the “HTML5 ecosystem.”

Given Google’s strategic interest in the web as an open development platform, its no small wonder that they have pushed this concept the furthest. Not only are they working on a project called Native Client to let users achieve “native performance” with the browser, they’ve built an entire operating system centered entirely around the browser, Chrome OS, and were the first to build a major web application store, the Chrome Web Store to help with application discovery.

While it remains to be seen if any of these initiatives will end up successful, this is definitely a compelling view of how the technology ecosystem evolves, and, putting on my forward-thinking cap on, I would not be surprised if:

  1. The major operating systems became more ChromeOS-like over time. Mac OS’s dashboard widgets and Windows 7’s gadgets are already basically HTML5 mini-apps, and Microsoft has publicly stated that Windows 8 will support HTML5-based application development. I think this is a sign of things to come as the web platform evolves and matures.
  2. Continued focus on browser performance may lead to new devices/browsers focused on HTML5 applications. In the 1990s/2000s, there was a ton of attention focused on building Java accelerators in hardware/chips and software platforms who’s main function was to run Java. While Java did not take over the world the way its supporters had thought, I wouldn’t be surprised to see a similar explosion just over the horizon focused on HTML5/Javascript performance – maybe even HTML5 optimized chips/accelerators, additional ChromeOS-like platforms, and potentially browsers optimized to run just HTML5 games or enterprise applications?
  3. Web application discovery will become far more important. The one big weakness as it stands today for HTML5 is application discovery. Its still far easier to discover a native mobile app using the iTunes App Store or the Android Market than it is to find a good HTML5 app. But, as platform matures and the platform economics shift, new application stores/recommendation engines/syndication platforms will become increasingly critical.

I can’t wait :-).

(Image credit – iPhone SDK)

22 Comments