I’ve been working on a lot of Pixel Bender experiments and wanted a nice UI to allow zooming in to examine the effected pixels. I decided to use the method of having an overlaid box on a scaled version of the image that corresponds to a zoomed separate display. I looked around and found some nice sample code on FLEX{er} written by Stelian Crisan. I mostly added nice UI to adjust the parameters in his code.
Apple’s way or the highway
| The Daily Show With Jon Stewart | Mon – Thurs 11p / 10c | |||
| Appholes | ||||
|
||||
Is Apple jumping on the crazy train?
I liked this article on Newsweek: Apple vs. Everybody: The company’s epic battle over a missing iPhone is only the latest in series of contretemps.
It’s the kind of attention that Apple, long a media darling, isn’t used to. Apple’s control-freak nature didn’t matter as much when it was a plucky underdog. Yes, Jobs was a demanding boss and a finicky perfectionist—but he created great products. We rooted for Apple, and wanted it to survive. Apple seemed like the anti-Microsoft, a company that was on our side. But this year Apple will do nearly $60 billion in sales, and its market value stands at $240 billion—the third-largest in the United States, bigger than Coca-Cola and Pepsi combined. Any company that big can seem a little scary. So when police start breaking down doors over a lost phone, it’s a PR disaster, especially for Apple. The company works hard to cultivate a counterculture image, with ads that have featured Gandhi and John Lennon, not to mention the “I’m a Mac” hipster. Yet lately Apple has started to look like the big bully of the tech industry, the kid who doesn’t play well others. Over the long haul, that can put customers off.
It definitely can put developers off (including this one), and when your platform has a lot of competitors gunning for it and a slim percentage of the desktop market, putting off developers is not really a very good idea. Apple is betting the company on their new strategy of a tightly controlled ecosystem where they make a small amount off of every transaction and act as intermediaries between content producers and developers and their customers. It will either be fantastically successful or Apple will crash and burn in a spectacular fashion. Only time will tell.
Moving to scrum: changes
So we started this product cycle with two geographically-dispersed mixed-discipline scrum teams on two week sprints. Specifically, the geographical co-mingling was designed to break up some of the silos that had built up on the team due to the existing functional teams being in different cities. By the third sprint, we’ve now switched back to scrum teams that mimic the original functional and geographic splits and are now on four week cycles. This has made cross-team communication more difficult, but has made everyone a lot happier by keeping the scrum meetings more relevant to everyone on the team. I can definitely see why people like this more, it lets people focus on what they are doing, but I do think we are losing something by not spreading the knowledge of the different parts of the project around the team. Also, not having multiple functional areas represented in the scrum meetings means that some fresh perspectives are lost in any of the technical discussions that come up. Over the next few sprints we’ll try this out and see if this is working. I think this will probably be what we stick with, and we’ll need to address the cross-team communication issues separately.
Switching to four week sprints was mostly to reduce the amount of time spent in the scrum meetings themselves relative to the amount of working time. Between planning poker, retrospectives and sprint planning, a lot of time is lost to the process itself in a two week sprint. For a team used to working on 6 week sprints, fitting stories into 2 week chunks was also difficult. I like the idea of two week sprints, but in practice, it was difficult for a team that is new to scrum. We’ll maybe try 2 week sprints in a future product cycle.
We still haven’t switched to our planned internally created scrum tool which itself makes things difficult. Our backlog is an excel spreadsheet and our tracking is all on Wikis. Hopefully, we’ll be converted over to the tool by the next sprint, which should make life a bit easier on me and the scrum master.
Pixel Bender Synthesizer Experiment
The subject of using Pixel Bender for audio processing on the Flash platform comes up a lot. Audio processing is very processor-intensive and math-heavy, so it would seem natural to leverage Pixel Bender to improve performance of audio within a SWF. At some point, last year, I was talking to Justin Everett-Church about doing a demo for Flash Player 10.1 multi-touch features. A synth seemed like a good idea, and it would let me kill two birds with one stone. So I coded up a synth (with a lame Flex UI) and Justin took that and made it pretty and added multi-touch support. That 2nd part of the demo never worked out the way we meant it too (missed the MAX 2009 keynote by this much). After that, I planned on cleaning up the code and posting it, but I got busy shipping CS5 and well, 7 months later, I finally got around to posting it. Right now it is just the playable demo with the crummy Flex UI.
It is a total processor hog, on purpose. I basically wanted to use it to push the limit of what could be done in the player, so I kept adding more filters and processors to it until the audio started to break up on my Core Duo 2 Mac Book Pro and then stepped back just a little. It turns out that you can actually do a ton of audio processing interactively in the player leveraging Pixel Bender. This was also designed to run as an AIR app, which means that if you really want to play with it, close all your other tabs. Really.
Pixel Bender Synth Experiment
Continue reading “Pixel Bender Synthesizer Experiment”
Section 3.3.1 is not new behaviour from Apple
[disclaimer: I am an Adobe employee and an Adobe and Apple shareholder, my opinions are my own and not those of my employer.]
Like the rest of the software industry, I’ve been pondering what the effect section 3.3.1 of the iPhone 4.0 SDK will have. I had fully been planning to make an iPhone application at some point. I had planned to do the initial version with Flex to prototype, but then also spend time doing a Cocoa version to better learn that SDK for myself. This iPhone 4.0 SDK announcement honestly has me questioning if I do really want to develop for the iPhone. Not just because of a higher-minded sense of indignity at Apple’s lack of openness of their platform, but rather because of that combined with their somewhat arbitrary and opaque app store approval process. Could I spend months of my spare time learning ObjectiveC and working on an iPhone application only to have that time be a complete waste if the App store reviewers decide that they don’t want that app in the store?
Thinking about it this morning, I realized that not only was Apple’s move to lock in developers nothing new, but that I’d already written about it before (in fact, I’ve been blogging about it since almost the day I started doing professional development for the Macintosh): iPhone SDK: The carrot for Cocoa, the stick for Flash, The difference between being an Apple developer and a Microsoft developer, Developers Developers Developers Developers.
Gruber had the motivation right, I think, but I also think he got the ramifications wrong. Since Steve returned to Apple, they have been applying the screws tighter and tighter to their developers, trying to get them to lock in. It was somewhat indirect at first, but the long term implication was clear: “We’ll tell you how to develop for our platform, if you do as we say, then you’ll be fine. If you don’t do it the way we tell you, your life will be a never-ending stream of headaches.” The move to Intel (forcing all developers onto X-Code and a big rewrite of any PPC-assembly) was step one, the move to 64-bit (dropping support for Carbon after promising it) was step two. The iPhone 4.0 SDK is just the most obvious move in this process because it basically spells it out. You no longer have a choice: it is Apple’s way or the highway. The problem is the App store. On the Mac, I control my own distribution. On the iPhone platform, Apple does. That means that they no longer have to negotiate with their developers, they can now finally dictate to them.
As a developer, this makes the iPhone platform a lot less attractive because I also can’t be sure that they won’t change the terms again. Once I’m locked in, I’m locked in. Apple can do whatever they want and I’m forced to rewrite my apps or get forced out. As someone who writes software for a living, this scares the crap outta me.
Here are some other blog posts that I thought were good reading around this:
The iPad isn’t a computer, it’s a distribution channel (O’Reilly Radar)
Five rational arguments against Apple’s 3.3.1 policy (37 Signals blog)
Wow, did Apple get the industrial design wrong on the iPad
I’m trying to write this on an iPad, thankfully one that I didn’t buy. Like many, I was intrigued when it was first announced. I’m a fan of Apple, if not a fanboy. There was a lot I’d been hoping for in the iPad announcement, most of which I didn’t get, but I still had some hopes for the device. I didn’t have enough blind faith to pre-order one though.
I’ve been using this iPad for less than a day, so maybe my opinions will change, but I don’t know how. My primary complaints so far are not about the software or the lack of features. My primary complaint is about the form factor. It is really bad, almost unusable on it’s own.
The iPad is too heavy to be held in one hand for too long. Even if you could hold it in one hand, the keyboard is then too wide to type with and difficult to type with more than one finger at a time. If held with two hands, it is too wide to type with your thumbs (phone-style) even vertically.
Since it is too heavy to hold in your hands for too long, you need to brace it on something. If you are sitting, you have to slouch or sit in an awkward position to brace it on your knee. Right now, I am having to sit cross-legged on the couch with two pillows on my lap to prop the iPad up in a semi-comfortable position. If you are sitting at a table, the rounded back of the iPad makes it difficult to use on a flat surface.
The iPad screen itself is wonderful, but the nature of the device itself means that it will be continually covered in fingerprint smudges that have to be wiped off.
Watching a movie makes the screen quality really shine, but also showcases the poor design. If you are holding the device in landscape mode (which is the logical way for video watching), you have a problem. If you hold the device so that the home button is to the right, your hands are either resting on top of the on/off button and the speaker grill or your left hand is blocking the headphone port. If you are holding the screen with the home button on your left, you are resting the bottom of the device on the volume rocker.
I hope that Apple addresses these flaws in future version, but I really have to say that so far, the iPad is really inferior in usability to the iPhone in my experience.
A tale of two customer support experiences
I’ve been putting together a mac mini-based home theater PC. I was going to post on it when I got it finished, but instead I have a different story.
Putting it together, I bought a few components and two different ones failed within two weeks (two weeks of each other and two weeks of opening their boxes). One was the Elgato EyeTV Hybrid. A USB-based TV tuner to record over-the-air digital TV. The other failed component was a Logitech DiNovo Edge (Mac Edition) bluetooth keyboard. Both of these are fairly pricey components, and are each somewhat critical for an HTPC.
The EyeTV just stopped being recognized by the computer. It worked fine for a few days and then poof. Dead. It happened right around the same time I did my first over-the-wire software update from them. I can’t say that it definitely was the software update, but very little else changed between when it was working and when it wasn’t. Rolling back to the previous software helped not-at-all. The computer doesn’t even see the EyeTv when it is plugged into the computer. For a device that is basically a few days old, this is a pretty crappy user experience. I contacted Elgato and they responded pretty quickly. After asking me the “dumb user” questions, they promised to send me a replacement quickly with a return label for me to return the dead unit. That was almost a week ago and I still haven’t received the new unit. Tomorrow it will be a week. That is unacceptable, I think, but I do like that they basically send you the replacement first and ask that you return the dead one.
Continue reading “A tale of two customer support experiences”
Unit Circle Magazine Archive re-launched
In 1993, I decided that I wanted to create a magazine. I don’t remember the exact reasons why. Zine culture was on the rise at the time and I was living in San Francisco, which was one of the epicenters, so it was definitely in the air. The first few issues were xeroxed and distributed around San Francisco, but were also posted at Postscript files on sgi.com’s FTP site and word was spread on the early internet newsgroups and mailing lists. The first issues were put together by myself, Jane Underwood and Derek Chung.
I moved to Seattle in 1994 and continued to put out the zine. Now, Dan Appelquist (editor of early science fiction e-zine, Quanta) had hipped me to this amazing site created by Paul Southworth, etext.org. Etext.org was all about celebrating literature on-line. In the proto-internet days of 1994, getting a website up was no mean feat, and keeping it up at no cost to the people being hosted on it was frankly amazing. Issues 3-6 were printed on paper, but were also hosted on etext.org. As one of the early culture e-zines it got some noteriety (including a write-up in the book “webworks: e-zines” by Martha Gill). Now that early HTML looks laughably primitive, but for the time I was quite proud of it. Issues 3-6 of the magazine were put together by myself, Derek Chung and Nita Daniel with some contributions by an occasional other writer as well.
After issue #6, I got very busy with Unit Circle Rekkids, and it also seemed like zines (both on-line and off-line) were just exploding. I realized that the tools were now in the hands of the artists that we’d covered and that the zine itself was no longer necessary. We left the site up so that the content was available, but it became a historic archive. I have to admit that I didn’t even check it out often any more to make sure that it was still up. The last content was added in 1996, I think, although some minor changes were made to the site afterwards based on requests from contributors.
Eventually, etext.org had run its course and the site itself stopped hosting its content. Unit Circle zine is still available from the internet archive, but I wanted to bring it back home and host it here as well so that it could live on as a time capsule. I have cleaned it up slightly (fixed up some of the links, scrubbed some of the e-mail addresses), but it is pretty much the same as it was when it was last updated.
I want to thank everyone who contributed to The Unit Circle Magazine, especially Derek, Nita and Jane, and I really want to thank Paul Southworth for creating an early home for culture on the internet. I also want to thank all the artists, authors and musicians who allowed us to showcase their work. I hope that all are successful and continuing to create. Finally, I want to thank everyone who ever read an issue, on-line or on paper.
The Unit Circle Magazine archive is now at http://www.unitcircle.com/zine/
Interesting UX presentation from Theresa Neil
RIA Screen Layouts
View more presentations from Theresa Neil.
The deck is a nice, loose, taxonomy of different design styles (some of the examples seem to have multiple styles to me), the examples are really good and actually pointed out some cool sites that I hadn’t heard about. Definitely worth a flip through if you have an interest in this stuff.
Moving to scrum: breakin’ the law
Well, part of the whole idea is that scrum isn’t a hard-and-fast set of rules right? I had some meetings at another office last week which necessitated moving out our first sprint review and retrospective a couple days. So if one of the guiding principals of scrum (and agile in general) is that the dates don’t change, everything else does, that got blown right out of the gate.
Some new stories came up as part of the sprint wrap-up which means that we’ll need to do a new planning poker session. Also, some other things came up which mean that there is a bit of housekeeping to do before we start the second sprint. We’re now in some uncharted zone between two sprints while the product manager and scrum master do some cleanup while the scrum teams do some off-book work for a couple days. Yeah, not ideal, but we’re trying to get it back on track. This sprint was going to be a throw-away anyway as it involved a lot of transition and getting used to the framework.
The retrospective brought up some really good issues and some innovative suggestions from the team on how to handle them. If the suggestions work out, I’ll post them here eventually.
There are still some folks unclear on what we expect to gain by transitioning to a new development process, but most of the team is embracing it as a good experiment and chance to try something new. For the most part, everyone seems to have an open mind and that definitely makes a huge difference as we all try to figure this out together. It hasn’t been the smoothest transition, but so far so good, I think. We’re definitely not as productive as we were before (so far). However, I think that the discipline provided by the product backlog means that we are actually getting the most important things done first. That makes a huge difference.