He attributes the growth to a change in buying habits: at first netbooks were seen as a second computer, but are increasingly being purchased as a primary device.
Intel's Atom processor for netbooks represented 20 percent of Intel's mobile PC processor shipments during the first quarter of 2010, according to an IDC study released last month. iSuppli last week said netbook shipments are projected to be 34.5 million units in 2010, up 30 percent from 2009. Total PC shipments are expected to be about 209.5 million units this year, an increase of 25.5 percent year-over-year.
These stats may surprise some who've been following the Morgan Stanley report suggesting that Apple's iPad has reduced interest in netbooks. But a closer look at that report reveals that the iPad's effect isn't limited to netbooks but affects a broad range of devices, even cannibalizing sales of Apple's own iPhone Touch and notebooks.
The reality of netbook success even with the advent of the iPad isn't surprising to those who've read the iPad's system requirements, which note that a Mac or PC is required to make full use of the iPad.
So what does this mean for Rev developers?
Over the years we've become accustomed to thinking of screen size as getting ever larger, and many software developers have begun to feel very confident that we could target 1024x768 as a minimum screen size to design for.
But netbooks are here and they're here to stay, so to capitalize on that growing segment it makes sense to make your layouts resizable, with a minimum useful screen size matching the netbook's WSVGA, 1024x600.
I've been reworing most of the apps I manage to make sure they work well with the shorter screens, and since the difference is only 168 pixels vertically it hasn't been too bad.
Resizable windows are the easiest of course, but we've had a few dialogs that were taller than 580 pixels (the screen size minus the Windows task bar or Ubuntu menu panel), and some of those required adjustments to work well.
But overall the process of ensuring that our software works well on netbooks has been pretty straightforward, and it's given me a good excuse to spend even more time with Ubuntu so I'm not complaining. :)
"I think it's a mistake for Apple to miss such an easy opportunity to acknowledge Mac developers," says Red Sweater Software proprietor Daniel Jalkut. "While the iPhone and iPad are understandably hot right now, the Mac is still a huge part of Apple's business, and Mac developers are important in sustaining that."
Rogue Amoeba CEO Paul Kafasis agrees. "Ultimately, I find these moves disappointing. Having an iPhone slant at WWDC is one thing, but completely cutting the Mac out of the ADAs? That feels like a snub to plenty of Mac developers who continue to do great work on a well-established, popular platform."
If you've been out backpacking for the last couple days and managed to miss the most important smackdown in the tech industry in months, Daring Fireball summed it up well:
So from Apple's perspective, changing the iPhone Developer Program License Agreement to prohibit the use of things like Flash CS5 and MonoTouch to create iPhone apps makes complete sense. I'm not saying you have to like this. I'm not arguing that it's anything other than ruthless competitiveness. I'm not arguing (up to this point) that it benefits anyone other than Apple itself. I'm just arguing that it makes sense from Apple's perspective - and it was Apple's decision to make.
Flash CS5 and MonoTouch aren't so much cross-platform as meta-platforms. Adobe's goal isn't to help developers write iPhone apps. Adobe's goal is to encourage developers to write Flash apps that run on the iPhone (and elsewhere) instead of writing iPhone-specific apps. Apple isn't just ambivalent about Adobe's goals in this regard - it is in Apple's direct interest to thwart them.
This morning a lot of development shops are trying to figure out how to affordably deliver vertical-market apps for iPhone without using modern high-level languages (HLLs). And a lot of these shops are being advised by their legal departments to take a "wait and see" approach with their iPhone deployments.
Here, Apple's "think different" has prompted us to think really different:
What if we just deploy to the other 75% of the mobile market* until Apple sorts out these control issues?
RIM still owns 40% of the market, and over the the most recent period I could find stats for Android has more than doubled its share while iPhone's has gotten a bit smaller:
And here's a plot of the rate of change over that period:
As an Apple shareholder I love Apple's margins and can appreciate their strategy here. But as a developer I have apps to deliver, and using single-platform APIs just to deliver to one minority OS is simply not viable for vertical-market apps such as those for which Rev and other HLLs are ideally suited.
Writing a highly-specialized app means you can completely nail a very specific problem, but it also means the number of customers is relatively small compared to a more general-purpose app. So for vertical markets return-on-investment is everything, and elsewhere across the software world such ROI is increasingly being delivered by HLLs.
Single-platform APIs simply won't deliver the ROI needed to make many specialized apps viable for iPhone.
The migration in the application development world to higher-level languages is nothing Apple can stop. It's been going on for more than two decades, has reached the tipping point over the last decade thanks to the ubiquity of the Internet, and seems likely to only continue to expand in this 21st century.
Indeed, the only question for Apple is whether they want to be a part of it, or attempt to reverse history by limiting developers to using the Assembler replacement that is C.
Between Java, Flash, JavaScript, Python, Rev, and the rest, Apple's "130,000 apps" can be eclipsed in about two weeks once all those mobile toolkits hit the market.
I know a lot of people who bought PCs because there wasn't "an app for that" on the Mac. It'd be a shame to see Apple squander their iPhone success only to replicate the marginalization they experienced on the desktop.
Let's take another look at that pie chart, expressed in terms of language choices:
Apple's new SDK licensing terms don't prevent developers from using a single high-level language to deploy their apps to most mobile devices. It merely excludes iPhone customers from enjoying them.
Sure, iPhone users will still have access to the really popular apps like Pull My Finger, but it's the other 75% of the world who'll get specialized product inventory apps, field reporting apps, sales quoting apps, and a few hundred thousand other vertical-market apps that will require high-level languages deployed across the majority of devices to have a worthwhile ROI.
There are a million vertical-market opportunities waiting to be discovered and capitalized on in the mobile arena. Using HLLs developers can write a single code base to cover most mobile devices with a greater productivity than is possible with lower-level languages.
These opportunities represent nothing short of a revolution.
Let's hope Apple decides to be a part of it.
* UPDATE - 12 May: Since I first wrote this Apple has revised their market share numbers downward to 16.1%:
Apple instead cited numbers released last week that showed the iPhone with more than 16.1 percent market share of smartphones sold worldwide.
Scripting Style Guide Updated Sun, Mar 21, 2010 7:19 AM
The Scripting Style Guide was recently updated to include this note about nesting conditional expressions:
When nesting conditions I've found it helpful to use a separate line for each condition, making use of the "\" line continuation character and putting the conjunction in all-caps to draw attention to it:
if (tWd is among the lines of the windows) \ AND (the vis of stack tWd is true) \ AND (the mode of stack tWd = 1) then ... end if
This means a few extra characters when you're typing, but the clarity is well worth the effort. Conditional expressions are the heart of complexity, and the more complex your code is the more difficult it can be to maintain and enhance. Giving them a little extra attention when you write you code can pay big dividends down the road if something breaks.
Being something of a late bloomer, I've begun adopting more the agile practices in recent months, and have been seeing good results: team members are more well coordinated, managers are happy with more visible results, customers are pleased to have features in their hands faster.
In some ways "agile" is simply a cool-sounding label applied to what us old-timers used to call "best practices". But there are some specifics to agile methods that are notable, perhaps chiefly by articulating a common set of principles from which all of our team members can derive specific practices on the fly as ever-changing requirements dictate.
I've worked in companies that were very practice-driven, attempting to reduce the dynamic complexities of development workflows into formulas and flowcharts because some best-selling business book told the owners that it would help them sell their company more easily if they could emphasize processes over people, making the company's value somehow independent of the people who comprise it.
But such process-worship often has the opposite result: it demotivates people, bogging them down with forms and procedures that too often don't reflect the ever-changing needs of the work.
And besides, it doesn't take a psychology doctorate to appreciate the people don't take well to attempts to make them replaceable. It doesn't inspire performance, encourages programmers to keep innovations to themselves, and this key irony isn't lost on them: all those flowcharts and documented Standard Operating Procedures somehow miss defining the owner, the one making the flowcharts, as a process-driven entity no less replaceable. ;)
In contrast, agile methods recognize that work is done by people, that people are the source from which an organization's true value is derived, and attempt to define common principles which inspire individuals to find their own specific practices on the fly as the dynamics of the work at hand require.
Such methods acknowledge that change is the only constant, and embrace change as the itegral driving force it is behind so much of the work people do.
The Agile Manifesto puts this succinctly, and is worth sharing here:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Bugs in Rev: a little perspective Sun, Mar 14, 2010 12:53 PM
I recently came across a post in the Rev forums expecting Rev to be bug-free, and this sort of thing comes up often enough from newer developers that it seemed worth addressing here, tagged with "FAQ" so hopefully it won't get lost:
When you get a Rev license you get bug fixes AND new features for a year. You can choose to get those for longer periods at a discounted rate through pre-purchase if you like.
But in a quarter century of buying software I've seen no viable product shipped with zero known bugs, and no vendor who promised to fix all them for free.
The operating system you're using right now - no matter which one it is - was shipped to you with no fewer than several thousand known bugs, and many more yet to be discovered. The browser you're using to read this - whichever it is - has at least several hundred known issues, probably closer to a thousand or more. And yet here we are, using them just the same.
Being closer in scope to a virtual machine than a consumer app, RunRev's bug count is more or less on par with industry measurements for quality in terms of number of bugs per KLOC ("thousands of lines of code").
Rev is far from perfect, and if one of the bugs happens to affect something that's critical for an app you need to deliver, you're no worse off than the rest of the world in being able to use any of the hundreds of other options for completing the work you need on time and on spec.
But by and large, for the work I do I've found Rev quite capable. Not at all perfect, but able to let me do what my clients need done with a higher ROI than we could get using other tools. And when we need something Rev doesn't currently support, we join the rest of the world and use a tool better suited for that specific task. The externals API is a godsend in this regard, since it lets us use a wide variety of other language for specific elements while still enjoying the productivity benefits of building the UI in Rev.
As you move forward with publishing your own software products, whether made with Rev or anything else, there's much to be learned from agile processes and many of the links found among the search results from that Google link.
The goal of software development is to put features in the hands of users as quickly as possible. Sometimes this will be the perfect feature, complete and bug-free, and other times it will work well for only 80% of your customer base while the other 20% will prefer to wait for some enhancement. If you choose to hold that feature back until it serves 100% of your audience, you wind up just punishing the 80% by not giving them the extra value they could benefit from right now.
What RunRev has learned over the years, and what I'm learning the more I adopt agile practices and what the rest of the industry is learning as well, is that it does a better service to your audience to give them what you have when you have it, and refine and enhance it as you go, far more than holding it back until it's perfect.
As one of those articles puts it, "Good enough is best".
As your own company grows to have an audience larger than RunRev's, I'd be surprised if you found a different pattern that delivered more value to more people in less time. And if you do discover such a Holy Grail you'll be famous, and likely rich, as it's been the pursuit of software publishers for decades.
Move your browsers to http://andregarzia.com/revlinux/ and check it out. So far I just put the VMWare Image out, the other images and LiveCD will follow shortly. This is a SuSe based distro with revEnterprise, revStudio, MySQL, PostgreSQL, Apache2, RevOnRockets installed. I created this from our emails yesterday till today, so it is a bit rough. I will polish it more if there's interest.
When Apple released their Macintosh IIfx, it was touted as a revolutionary machine, "wicked fast". Code-named "Stealth" and "Blackbird", it had a new motherboard architecture that featured custom coprocessors making it, as Steve Jobs said at the time, "the first zero-wait-state computer". Exciting stuff.
But still, something in the deep recesses of my lower brain told me it would be a short-lived architecture. I don't really know why, but after I finished the issue of MacWeek describing it I turned to a coworker and said, "I give it 18 months." I was off by six: Apple discontinued the model two years later, replacing the line with a different architecture which dropped much of the proprietary chipset that few developers had bothered to compile for.
In the late '90s I saw how much Apple was spending on R&D making their PowerPC chips, and by that time I'd used enough Intel-based machines that I risked the wrath of a few of my fellow Mac friends by suggesting Apple would do well to move their computers to Intel. My friends tried to explain to me the many benefits of the superior PPC architecture, but I maintained that compelling as they may be they weren't quite enough to offset the massive additional expense.
Over time, with Intel supported by pretty much the entire rest of the industry while Apple was the only mainstream computer manufacturer using PPC, whatever performance advantages had favored PPC began to give way to Intel's advances, and in 2005 Apple switched to Intel for all computers going forward.
Sometime around the turn of this century I had been using two- and three-button mouse-driven OSes (Windows, Sun OS, and Irix) just long enough that it seemed reasonable to suggest that Apple would one day ship with a multi-button mouse. The OS already supported third-party multi-button mice, but using an Apple mouse at the time required you to use the cumbersome Control-click to access contextual menus. Ugh. Even Bruce Tognazini, who had founded Apple's Human Interface Group, said "The two-button mouse is seven or eight years overdue."
But oh did I catch hell for that one too, with a few friends calling me "crazy" and "anti-Mac" for even just suggesting the notion. In 2005 Apple started shipping mice with multi-button functionality, and the sky didn't fall after all. Instead, there's just a little less RSI in the Mac world as people make fewer trips up to the menu bar.
Shortly after Apple premiered the infamous "hockey puck" mouse I predicted its demise too, but in all honesty that was an obvious one everyone saw coming.
So those are my qualifications as a soothsayer.
In all fairness, I've had a few misses too: back in the '90s with my 56k connection I predicted that video wouldn't be important on the Web. :) Win some, lose some.
With those qualifications in hand, I'll walk out to a slender limb with a prediction for the iPad.
This is not the device they were hoping to deliver.
For whatever reasons, technical or otherwise, the iPad we saw yesterday is a compromised prototype of the touchscreen UI for something yet to come, a mere stepping stone toward a product that'll look very different by the time it's fully realized.
Steve Jobs is a serious thinker, and when he says he wants to define a whole new category of device, I believe him.
But in its current form, for all its beauty the iPad is functionally more of a large iPhone than a truly third category of device.
It weighs the same as a netbook, costs more than a netbook, and supports a far narrower range of computing tasks than a netbook. Some of Jobs' arguments against netbooks are valid, including to some degree his observation that "Netbooks aren't better than anything." So why not best them?
"But it's not designed for computing, it's a media viewer!" Well, that, but also an email client, and a iWorks interface, and osensibly a lot of other things that push the limits of its design into an area that suggests it wants to be a computer, but sacrifices a lot of computing functionality just as much as it looses screen real estate the moment you want to type.
Given the egonomic challenges of a virtual keyboard on a single-panel device, I might even go so far as to predict that the iPad we see next year or the year after will have a folding screen, giving us the benefits of a laptop while also delivering an optimal movie experience.
I wouldn't be surprised if the iPod-to-be also runs OS X in addition to iPhone OS, a capability that may find its way into a future release of OS X itself (OS XI?) for all of the computers Apple makes. Think Dashboard, but deeper.
My hunch is the iPad as we know it today will live about 24 months while Apple prepares something truly amazing. This was good, but the reviews thus far have been mixed, noting its limitations relative to the mind-blowing "Wow!" Apple normally delivers.
I believe that mind-blowing "Wow!" is on its way.
Crazy? Missing the point? Wouldn't be the first time. :)
Too tall to live, too weird to die Fri, Jan 29, 2010 9:13 AM
Many years ago there was a catalog of novelty items based around the infamous Chickenboy, a large statue of an anthropomorphic chicken marking a restaurant in Los Angeles.
The slogan for the catalog was, "Too tall to live, too weird to die". See for yourself:
Before we get to the point of this post, it may be helpful to remember exactly what "weird" means: "involving or suggesting the supernatural". Regardless how people use it, "weird" can be a good thing. A very good thing. Keep that in mind as we go forward here:
So last night I was pondering Apple's premier of their new iPad as I walked past a cafe, and I noticed nearly a dozen people inside with their laptops open, almost half using netbooks.
As one does at a cafe, they were mousing the track pad with one hand as they sipped their latte with the other.
And that's when it hit me:
"What happens to your lap when you stand up?"
Or more specifically in this case, "What good is your lap when you're at a table?"
The iPad is a beautiful thing in so many respects, but ergonomically it's limited to use on your lap. When sitting at a table, such as any of the thousands of Internet cafes where people enjoy their surfing, the iPad must be held with one hand to keep it at a readable angle, requiring you to choose whether to sip or surf with the other since you don't have a third hand to do both.
I suppose you could prop it up with your backpack, provided you also brought a book to rest the iPad's bottom against to keep it from slipping forward to knock your coffee cup off the table, or you could shell out a few extra bucks for the nifty stand Apple will make available.
But whether or not you cart your stand around with your iPad, you still have to bring the iPad itself. How do you do that?
Until the iPants show up at your local Gap, if you want to enjoy your iPad anywhere outside of your house you're looking at a backpack or shoulder bag. If you were looking for a pocket-ready device for the iPhone OS you love, your iPhone remains the solution. With the iPad, you're back to where you were with your netbook: roughly the same size and weight, you'll be putting it in your backpack.
But you'll be putting it in that backpack very, very carefully. With no claimshell, the screen is always exposed to whatever else may be in your pack. Even with a slipcover, you'll need something hardshell to protect your investment from the rough edges of whatever else is in your pack.
Okay, so we've worked out a strategy for safely getting our iPad to the cafe, and we've accepted that while we're using it we're going to take a brief pause now and then from the touchscreen to sip our coffee. Fine. But what do we do when we want to type a URL, or reply to an email?
Propped up as we have it for a good reading experience, the iPad's virtual keyboard is now at an angle somewhere between uncomfortable and impossible for typing. So we move our coffee cup out of the way, nudge our pastry to one side, put the book we'd been using as a brace for the iPad back in our pack, and rest our lovely new device flat on the table so we can type.
I'm not sure exactly what happened to restaurant designers over the last ten years, but the prevalence of halogen spot lighting, however economical it may be, plays havoc with our eyeballs from glare. They're great for illuminating art at galleries, but uniquely crappy for ambient lighting where they're so often misued. So when you rest the iPad flat on the table to begin typing, if you've been as unlucky as I have to find yourself in too many cafes using halogen lights, you'll want to bring that book back out of your pack to prop up the top of the iPad at an angle that moves the blinding reflection away from burning a hole in your retina. Sure, that's not an iPad failiure, that's a restaurant design failure, almost as bad as the nearly complete absence in the 21st century of any restaurant whose walls are not lined with noisy televisions. What's up with that? When did they decide we need to stop talking to the person we invited to sit across the table from us and just watch TV instead? But I digress.
Since the case is slightly curved on the back, you'll probably want to prop it up on something anyway, since, as Gizmodo notes, when you lay it flat on the table it has a bit of a rocky rolly feel, making typing that much more difficult.
"So what's your point?" Hold on, almost there. Let's first go back to the living room:
You're sitting on the sofa, with your legs crossed as Steve himself so casually demonstrated on Wednesday:
Looks comfy. Really comfy. You can even change which leg is crossed and still be comfy. Nice.
But what happens if you have an ottoman, if you're as lazy a sitter as I am and you like to have your legs extended? Against what do you prop up the iPad when you're leg isn't up anymore?
I guess you'll be holding it.
There's another, though less significant, point as well. Here's an ergonomics diagram of sitting:
Sure, as an example of office ergonomics it's almost entirely irrelevant to a discussion of what we do in our livingroom, except for one detail: note the angle of the neck for viewing the screen.
A laptop elevates the screen above our lap somewhat to come at least a little closer to that most comfortable angle, even with your legs extended. But the iPad is all screen, and rests directly on your lap a few degrees lower. Two movies later and the effect on your neck angle adds up. Yes, it's close to ideal, but not quite as close as your laptop.
Before I wrap this up I should note how much I respect and admire Jonathan Ive, Apple's lead industrial designer. He's an absolute genious, and rightfully one of the most influential figures in the industy.
Which is why (yes, here we finally get to the point) I have to wonder why the iPad is designed to be used comfortably in exactly one position, the one Steve showed us in the demo, sitting in a chair with the device propped up against one crossed leg.
At a table you need to prop it up, with your legs extended you need to hold it, and when you want to type you need to move it to a more level position less optimal for viewing but the only practical way to work with the keyboard.
Sure, you can get the desktop support for it, along with the add-on physical keyboard. But once you put all that together, it looks like this:
...which looks a lot like this:
But there's one thing your laptop has that the iPad doesn't: OS X. A rich, multitasking OS, on which you can load any apps you like from any source.
Yet for all that, there is a certain appeal to the iPad. It's certainly beautiful to look at, and reportedly feels good in your hand (which is important since you'll have to hold it much of the time).
As an attempt to define an entirely new space for computing, it's a really weird product, in the good sense of the word. But with a form factor that makes it combersome to use outside the livingroom, and even there it's not without some compromises, it's arguably "too tall to live".
So what will become of the iPad?
I'll step out on a limb with a prediction in my next post.
Those of us who once loved Oracle Media Objects have no great love for the company that killed that fine tool (my first cross-platform xTalk), but in spite of my own personal misgivings about the company I must admit on this one I'm in the "what, me worry?" camp.
Amid the ambiguity that afflicts Oracle's plans for the future of MySQL, a number of third-party vendors with close ties to the open source project have stepped up and professed a strong commitment to shepherding future development by maintaining community-oriented forks. Several of these companies have jointly established an organization called the Open Database Alliance which promises to provide a vendor-neutral environment for coordinating this effort.
MySQL is open source, so there's nothing preventing forks from filling in any gaps Oracle may create. If Oracle renigs on its promise to maintain MySQL as open source, even if the licensing nuances Ars Technical points out may inhibit furthering that specific code base, there are enough other truly free FOSS db engines to fill such a void.
Sure, that would be disruptive. But I don't think the sky is falling. At least not right now.
RevWeb security warnings: use sparingly Mon, Jan 4, 2010 11:20 AM
Would you be so kind as to email me a copy of your birth certificate and all of your credit card numbers along with the security codes from the back?
Sure, most of you don't know me, and with that info there's no end of damage I could do to you. But at least I'm asking politely, and isn't that enough to earn your trust?
Of course this is an absurd request, but think about it: when you deploy a Revlet on a public site that tells the user it needs access to their hard drive, is it all that much different?
Will your Revlet be reading files from my drive and sending them to your server? Will it install trojan horses? What exactly does it need to do that requires access to my drive?
A surprising number of Revlets I've come across ask me for access to my drive, probably more than half of them.
I've asked a few of the developers of those Revlets why their app requires access to the user's hard drive, and in most cases it's for trivial things like storing preferences.
RunRev's free browser plugin is a wonderful opportunity for deployment, but using it to deliver a great browser experience requires that we recognize it's more than just a way to deliver our stacks without having to download the engine.
If it's in the browser, it's a very different experience altogether, one that suggests we rethink even common things like preferences in ways that make good use of the web.
Any new plugin will be compared to Flash, the de facto standard which has been bundled with every major browser release for at least a decade.
Flash developers rarely rely on locally-stored prefs. Why should they? Cookies can be used to store small amounts of data, and for anything larger the cookie can reference a database record for the individual user stored on the server.
If you're going to use the web, use the web.
If there's a benefit to liberating your users from needing to install a desktop app, liberate them fully and leave their hard drive alone whenever you can.
Sure, there may be some sophisticated Revlet applications which can and perhaps should make good use of the user's drive. But such potentially-dangerous local access should be relied on sparingly, perhaps only in educational or other organizations where you've already established some trust with the end-user.
When we publish stacks for the general public we really need to slow down and ask ourselves:
"Is it truly necessary to have access to the user's drive?"
"Will this turn people off to my work?"
"With this turn people off to Rev?"
For RevWeb to be adopted, we need to do our best to make folks comfortable running stacks with it. If we get lazy and just rely on local storage for even simple things like prefs and high scores, we risk scaring them off, leaving them with the impression that RevWeb is a dangerous thing.
The warning dialogs are a very useful part of the RevWeb experience. Let's make them more useful by using them sparingly, avoiding them completely whenever possible.
Installers making a comeback on Mac? Sat, Dec 19, 2009 12:40 PM
Using a computer means using apps, and using apps means installing them. For years this meant downloading and runing an installer, and it still does on Linux and Windows. But with OS X we've seen a migration to using disk images ("*.dmg" files).
For those of us who make software for a living this seems simple enough: double-click the DMG, double-click the mounted volume that appears, drag the app to your Applications folder, and you're done. What could go wrong?
If you've ever tought a complete newbie how to do this, or even someone who's had some Mac experience but installs downloaded apps infrequently, you've seen the problems.
First, they downloaded only one file, so why do they have two icons on their desktop? Of course you and I know that one is the DMG archive and the other is the mounted volume showing the DMG's contents, but this isn't always clear to everyone.
In fact, it's rather inconsistent with nearly every other icon they've enountered. Most icons are discrete things, a file or a folder: it's a single thing that you can move or even throw away as you like.
But many think that when they see the second icon (the mounted volume) it's a copy so it's safe to throw the first one away, the DMG file. Of course if they try that the OS tells them they can't because "it's in use", but it may not be readily understood that the thing that's using it is the mounted version of it, that second icon.
Also, many folks aren't clear that you should move the app to the Applications folder. Why should they? After all, most apps run just fine from the mounted volume. They see it, they double-click it, it runs fine, and when they're done they toss the file they downloaded, the DMG file, because obviously they don't need it anymore. Oops.
Sure, you can include writen instructions in the background image of your DMG archive to tell them to copy the file to the Applications folder, and many do. And sure enough, most users aren't complaining. But some do, so it raises the question:
Are DMGs really a better option to an installer?
We could weigh the pros and cons, but I think it's safe to say that after we consider all of the tradeoffs the best thing we could say for DMGs is that the benefit of using them to deploy applications is debatable, but not certain.
And keep in mind that in the modern world most folks in a position to buy a new computer have probably used one before, which means that most of those who are new to Mac OS have probably used Windows before. In Windows it's extremely rare to be able to use an app without first running an installer. Pretty much the same for Linux as well.
Of course all OSes have differences, and slavish devotion to any sort of common convention just for the sake of conformity would strip an OS of it's unique value, the reason for considering it at all.
But installing an app is a one-time thing, with (hopefully) far more time spent inside the app using its features. Surely there are many other opportunities to show off the value of an OS than making DMGs only because "it's more Mac-like". Seduce the new user with a familiar experience, then impress them with distinctions that matter.
Besides, what's the downside of using an installer? Anyone who can use a DMG properly can use a reasonably made installer, but the opposite may not always be true.
I've included some blog links below that discuss this issue. After reading them, I'm considering moving my future Mac deployments away from DMGs to installers.
This update includes a discussion of the dispatch command, and provides a bit more detail about the differences in using parameters with send, call, and dispatch.
But apparently in honor of Halloween, Microsoft has instead chosen to horrify us with the creepiest, most cringe-worthy launch ever.
You see, someone at Microsoft (who probably won't have a job after today) had the "brilliant" idea that thousands of consumers would want to host their own launch parties for Windows 7 in their homes.
Yes, you read that correctly.
They even set up a site to get you going: houseparty.com
But that's not the lame part.
No, really, it gets worse.
Much worse.
Someone at Microsoft (perhaps the same soon-to-be-another-unemployment-statistic person) decided that maybe some of the folks who want to host "house parties" for Win7 may not know just how to go about it.
So they made a video.
No, really.
They made a tutorial video on how to throw a party.
I kid you not.
I take back everything I said yesterday about lame marketing campaigns. This one wins the Lifetime Achievement Award for Lameness in Marketing.
Beyond words, it simply must be experienced to be appreciated. Click, if you dare:
Smartphone competition - at last Wed, Oct 21, 2009 9:44 AM
The iPhone is a great product in many respects, but its closed architecture, Apple's draconian sole-source app distribution, and lack of a physical keyboard with real feedback have kept me, and a few others, waiting for some real competition.
With a strong competitor we might see Apple push the boundaries a bit more, and perhaps open their closed system to a wider range of development and distribution options.
Until recently, those of us waiting for competiton have been disappointed.
Sorely disappointed.
First, T-Mobile teamed with Google to produce what may be the least interesting ad ever created for a technology product:
Metamessage conveyed: "This phone has custom wallpaper."
I can't recall a phone that didn't. If there's anything else going on with that product it would have been good to let us know. It seems others are underimpressed as well.
So when I heard about the Palm Pre I was very excited. I bought one of the first editions of the Palm, and upgraded a few years later. While the file format for the Palm OS was needlessly cumbersome to work with (is plain text really too complicated to support?), at least it was open with widely available tools to write all sorts of fun stuff.
Since Palm had pretty much validated, if not invented, the whole handheld market once upon a time, I had high hopes they'd pull off a great comeback with a solid entry and a marketing campaign to match.
Well, not so much.
The Pre may be a fine phone, but with a marketing campaign based around a vacuous-looking alien girl who eventually waxes philosophical but never quite gets around to telling us what the Pre actually does, no one cares.
Here's one of the many disturbing examples from this campaign:
Metamessage conveyed: "Buy our phone and you'll become an alien spirit being."
I was just about to give up on the dream of ever seeing a competitive market for handhelds....
...but then I saw this:
Metamessage conveyed: "We're about to kick some serious butt."
No THERE'S a game-changer.
Confident, brash, tells us exactly how the product differentiates, fully acknowledges that it enters an iPhone-dominated world and approaches that task head-on. Bravo.
After an ad like that I can't wait to see the Droid in action. Good specifics offered with a touch of mystery. No wonder it's the talk of the town.
Too bad no other competitor could pull that off, but I'm grateful at least one vendor gets it.
Benchmarking performance Wed, Oct 21, 2009 8:34 AM
For questions about the relative performance of different ways of solving a problem, it's often faster to just test it than it is to post to the list and wait for a reply.
This is also helpful because you'll know first-hand exactly which one performs better, and can tweak your tests to refine them further if needed.
Also, as a bit of a benchmarking geek I've found that results will often vary according to the data you're working with. For example, one common rule of thumb is that arrays are always faster for accessing data elements than chunk expressions, but having looked into this in detail I've found that's not always true depending on the specifics of the task at hand (I'll get into that more later, as some of the results were rather surprising but ultimately understandable).
Here's a simple script you can use as a template for benchmarking relative performance - just put this in a button, add whatever code you want to test in the two places noted, and click:
on mouseUp -- Many tasks are so quick they don't show a measurable -- difference unless they're run multiple times, so we -- run through the number of iterations specified here: put 1000 into tIterations -- -- TEST 1: put the millisecs into t repeat tIterations -- Do one test here:
end repeat put the millisecs - t into t1 -- -- TEST 2: put the millisecs into t repeat tIterations -- Do comparative test here:
end repeat put the millisecs - t into t2 -- -- DISPLAY RESULTS: put t1 && t2 end mouseUp
Note that tIterations is set to 1000 in this script, but depending on what you want to do that may be too small. For some tests I bump it up to 10000; that's why I have it on a separate line, so it's easy to change when needed.
Another way to test these sorts of things is with RevBench, a free tool available in the Stacks section of RevNet.
In Rev, see Development->Plugins->GoRevNet
RevBench provides a simple but convenient way to run two script snippets to see which is faster. Lately some of the benchmarking I do is too complex to fit into that setup so I tend to use the script I posted above, but for simple tests RevBench can be handy.
(Those who use Fourth World's Resource page as one-stop shopping for all things HIG will find I've added that link there along with the other HIG pointers to systems Revolution supports.)
While it's no easy trick to come up with color, gradient, and icon schemes that work well on multiple platforms, it seems Windows 7 may finally provide the motivation to push the Windows side of your deployments a little harder to fit in gracefully. It will for me. Snow Leopard has some nice features, but I think it's been a couple years since we've seen an OS change the landscape for multi-platform UI designers as much as Windows 7 does. If nothing else, it legitimizes the Vista look and feel by finally making it worth using.
Now the big question for us Rev developers is: When will RunRev provide support for multi-touch gestures? Simple mouseUp just doesn't cut it in the 21st century.
In a recent post to the use-rev list someone asked about the order in which messages are sent by the Rev engine. This warrants a more complete discussion here at revJournal, but for now we can at least hit some of the essentials:
-- Starting a standalone: startUp
-- Opening a stack: -- The "pre" messages are sent before the window is rendered on screen: preOpenStack preOpenBackground -- sent once for each shared group on the card preOpenCard -- These are sent after the window is rendered: openStack openBackground openCard appleEvent 'miscoapp" -- Mac only
-- Closing a stack: closeStackRequest -- sent if the user clicked a stack's closeBox -- If the closeStackRequest message is not passed the close messages aren't sent, -- but note that that only applies when the user has clicked the closeBox; -- closing a stack via script will always send the following messages: closeCard closeBackground closeStack
-- Shutting down: shutDownRequest -- if passed, shutDown continues shutDown
All of these messages are sent to the current card, and pass through the message path as described in this article.
Designing software upgrades: How far is too far? Sun, Sep 27, 2009 9:49 PM
I have three software products undergoing the most significant upgrades in their respective histories, and one of the central issues we've been dealing with on these redesigns is how much can we change things without disorienting our loyal users?
Users hate change, so it's usually best to stay with a familiar design and evolve it gradually. In the long run, however, incrementalism eventually destroys cohesiveness, calling for a new UI architecture.
I felt a bit lucky stumbling across that just when I did. Hope it does the same for at least some of you. A short read, but worth it if you work on long-term multi-version projects.
Saving data from revlets Sat, Sep 26, 2009 12:18 PM
With RunRev's new plugin to run stacks in the browser I've seen a lot of questions about how to save changes the user makes in those stacks.
With distributed systems like this the challenge is that there is no "there" there. :)
That is, the revlet stack file is indeed sitting on the server, but in an inert form. It's just a blob of binary data that the server copies to anyone who asks for it.
What's running in the browser is a copy of the file that's been downloaded over the web, hundreds or maybe thousands of miles away, on the client computer.
Since we can't have random web browsers altering files on our servers, no client process can write to a server file system directly. Instead we must go through some other intermediary process designed for such communication, like FTP, POST, or GET. The latter two are most commonly use in web apps, and fortunately the Rev CGI engine makes it pretty easy to accept such data to do anything you want with it on the server side.
I was curious about what Cos Russo has been up to since he released the port of Alida he'd made with Rev, so after a quick search I turned up this interview from last November:
The rect option can be useful at times, but since v2.7 we've had a much easier and more robust method of exporting images of objects by specifying the object itself rather than a rect:
import snapshot from img "MyImage"
The object needn't be an image; it can be anything other than a stack (referencing the card will work for those), even groups.
The big difference is how the image is generated:
Using the rect option cips a portion of the display buffer, so if your image is out of bounds there won't be anything to get.
But using an object reference causes the engine to render the object into a private buffer for you, much like it would do when rendering the image on a card, and then hands that buffer back to you in the resulting image.
In my experience using object references is reliable under a much wider range of circumstances than using rects, even with objects on cards that aren't open.
Difficulties with using the from rect option come up often enough, and the from object option is so easy and flexible to use, that it seemed worth filing that here under FAQs.
