There is plenty to be said for (and against) the new iPhone and all the new apps flooding to our screens but aside from the sluggish response times and occasional crashes, the biggest problem I have is keeping track of and organizing all these apps.

Applications of all types are now spread across multiple screens as I try, mostly in vain, to come up with a strategy that doesn’t leave me needlessly flipping through 3 to 5 pages just to find the thing I want. I have tried to organize them by grouping like apps together on screen but I don’t really want a whole screen for music-related apps or games. Then I tried by frequency of use with the most frequently used apps on the first couple screens and then those I rarely use on the last few. This too was less than ideal as it isn’t readily apparent when I am search for something how many times I really use it. I guess I could try alphabetical.

How about adding folders?

The folder is a simple organizational mechanism that could help keep my applications in order: Creating and naming folders and then dragging apps into them could work nicely. (like shown above)

Double tapping the folders brings up a radial menu of its contents - app icons - that can be clicked. I have mocked up how that may look (see below). A simple, dark overlay similar to a lightbox effect to represent the mode change would work well.

This example only shows a folder with six applications in it and I am uncertain how to deal with folders containing more than eight. Perhaps there would be a number on the the folder and then single tapping would tab through them.

Until I get something like this the number off application I will be downloading will be significantly restrained.

Bonus gripes to Apple:

1. Please let us delete (or at least hide) those app you included on the phone that we do not use. I don’t need stock quotes and notes.

2. When updating an app, don’t move its position. This is very annoying.

3. Get the stability and fluidity of the interface back to the point where it was when the phone first launched. I don’t think you can totally blame the apps being installed, but if you can, then be more stringent on the apps you let in the store.

4. For next iPhone INCREASE THE RAM!

Lean-to is live! We haven’t done a great job of keeping the work we have been doing under wraps but we haven’t been promoting it either. Since we gave a demo of our agile project tracking application, Lean-to, at minnebar in May, we have been adding features and tweaking it until we were ready to start talking about it.

We wanted to let everyone know that we have pushed out some significant updates to Lean-to that we hope will get people excited. Here are a few of the highlights:

• Add people to your account and manage settings
• View plan and backlog views for your stories/bugs
• Track team progress with report views
• Get more info on list views with new context menus
• Add tests to stories in improved ways
• Assign stories or bugs to iterations from the backlog view
• Filter lists to show only those stories or bugs assigned to you
• More invite and project options
• Various interface improvements

We hope that you enjoy the new changes in this release and we ask that you don’t hesitate to use the feedback link to let us know what you like and don’t like about Lean-to.  We’ve got lots more on our own backlog, but we’d love to hear what you want from Lean-to.

(more…)

This is a little bit older, but pretty interesting: Nine Things Developers Want More Than Money.

It should be inherently obvious, but seeing lists like this every once in a while is a good reminder that creating and maintaining high-performing teams is clearly more about people than it is about process, technology, or anything else.

Much has been written in blogs and in the news media about Best Buy’s Results Only Work Environment (ROWE). And while the idea (do whatever you want, work however you like, as long as you get your work done.) is cool and it is nice to see a big company embracing some agile ideas, this is not a post about ROWE*.

As a follow-up to my post earlier this week, I wanted to post some pertinent bits of a recent discussion I had with Geek Squad founder and current Best Buy executive, Robert Stephens. He is implementing a plan to “think small” from inside the behemoth that is Best Buy. Stephens’ plan addresses each of the points that Mike Speiser of laserlike.com concludes are important advantages that startups have over large organizations in terms of innovation, namely: the investment model, incentives, and risk taking.

His idea would focus on technology and software solutions developed by small teams or individuals within Best Buy (or failing that, using small teams or individuals from the outside). The first step would be to create an infrastructure that allows for projects to get up and running with very limited administrative or technical setup. Once a problem or opportunity is identified, employees are encouraged to bid for the opportunity to tackle a problem by offering up their solution and what it would take in terms of time and money. The best ideas are funded (in the form of a bonus) or, in some cases, combined into teams. We aren’t talking about large “corporate-type” budgets either - these could be a couple thousand to twenty thousand dollar budgets. The goal is to side-step the typical flow of events in corporate business: get an idea, meetings and discussion, document the idea and discussions, sending the idea “up the flagpole”, having more meetings, having the idea morph, incorporate additional ideas, and finally either get the “green light” or be canceled weeks, if not months after the solution would have ideally been implemented.

This concept allows Best Buy to act like a startup in all the ways that are important. It allows for “distributing investment and other decisions” (a new investment model) across the organization allowing for risk-taking by individuals who are incetivized by the ability to create something great and get paid extra for their efforts.

* For more on ROWE, check out this Tim Ferris post for more on ROWE or the blog of ROWE instigators Cali Ressler and Jodi Thompson.

Jason Rudolph has a great post discussing getting started with git, the new kid on the block for version control.

That post alone makes a compelling argument to me for trying it out. This quote hit a little too close to home:

Do I really want to create a new repository just for this experiment? Should it go in my local repo, or does it belong up on the shared repo? Should I bother setting up the standard dirs for trunk, tags, and branches? Maybe I should just add it to a grab-bag repo for now? Nah. Forget it. It’s not worth the trouble yet.

Other benefits aside, ease of setup is a killer feature for me.

If you are like me you use Gmail and love it. You also use a Mac and have found Firefox has started to become too bloated and slow to use for accessing your Gmail. For a while now I have been using Gmail as it’s own “stand-alone” application using Fluid.

This has been nice for a couple of reasons:

1. It gives me browser independence. If I want to use Firefox for development, say, I can. If I want to browse the web with Safari, because the experience is better, I can. But I don’t need to have either up and running to check mail.
2. I can fire up Gmail from spotlight (which I use like Quicksilver). I hit Cmd + Space hundreds of time a day to search my computer and launch programs. I need just hit Cmd + Space and then “G” and Return and Gmail is open.
3. The Gmail logo sits there looking pretty in the dock.

But then Safari 3.0 was released. Despite numerous improvements, the change that effected me the most was one that didn’t allow my Gmail Fluid app (which used Safari) to add contacts by tabbing (only return works). I have enough muscle memory built up that this was actually a major problem for me every time I would search for and add contacts.

Then, when looking for info on Firefox 3 I saw Camino sitting there and remember using it before. Well I downloaded and installed it and for a speed test, openened Gmail. To my surprise it was fast - faster than it has been in years I would say. This got me wondering (aside from contemplating using this as my primary browser) if I could replicate my Gmail.app Fluid file using Camino somehow. Well, it turns out not to be that hard. Here’s how I made my Gmail faster and more usable:

1. In Camino > Preferences > General Tab - make sure to check the box next to “Load the pages that were open before quiting” (and choose the default browser in which you would like links to open)
2. Adjust any Tab preferences while you are in here.
3. In Camino > View - choose to hide the toolbars, if you wish to make it seem more application like. You can always turn them back on by clicking the lozenge in the upper right corner of the browser window.
4. Now that the boring stuff is done, find Camino in the Finder and choose “More Info”. Change the application name to Gmail.app.
5. For this last step it helps to have had a Fluid app already installed that uses the Gmail logo. As this is the only way I know how to easily do this, just open the Fluid app and click on the icon in the upper left and hit Cmd + C to copy it.
6. In the new Camino/Gmail app click to select the Camino icon in the upper left and hit Cmd + V to past the Gmail icon. Viola’, a fast Gmail app that is readily accessible via the OS.

Only a couple things have bothered me during this past year’s transition to OS X. One of them has been Firefox’s issues with tabbing through form fields. Specifically, how it can tab through text fields and textareas but not dropdown lists.

Safari has the the same problem but it is easily remedied via System Preferences > Keyboard & Mouse controls. Clicking the Keyboard Shortcuts tab/button at the top and then the radio button labeled “All Controls” will enable tabbing into dropdown lists.

UPDATE: As it turns out (as of some update) the System Preference change above will affect both Safari and Firefox so you do NOT need to do the steps below, if you have all the updates.

But the Firefox fix had been more elusive, until today, I just couldn’t take it anymore and search again. Eureka I have found this post. It is a bit less user-friendly but here are steps to get Firefox forms up to snuff on the Mac:

1. Type about:config in the URL bar.
2. Click inside the Filter field that will pop up, and type tabfocus. This will narrow down the listed preferences to accessibility.tabfocus, which is what you want to edit.
3. Double-click this preference, change the value to 7, and then restart your browser.

This will save me a bunch of time and a good deal of moving my hand to my mouse and back.

Application Architect for ThoughtWorks, Neal Ford comments on the homebrew (or what he calls craptaculous) framework and what he thinks of Grails as it approaches 1.0:

Which suggests a clear new front runner in the Java world: Grails. Because it is based on Groovy, not Java, the perception is that it is the only game in town. That will help drive the adaptation of Groovy like wildfire. In fact, I think that Grails is the engine driving the interest in Groovy. New languages are cool and all, but until you have something to do with them, they don’t catch on (look at what happened with Java when servlets came along).

Of course, I would be remiss not to mention that Rails now runs on the JVM via JRuby. However, I think this is perceived by many in the Java world as a bigger transition than Groovy and Grails. Ruby is a completely different language, with different idioms. To hard-core Java-ists, Groovy is practically Java, with most of the stinky parts removed. Once Grails becomes 1.0 and beyond, it may be salvation from the home-grown Craptaculous framework that Java developers are still using.

We have seen adoption of the Grails framework increase as more and more developers push for it from the “bottom up”. We are excited for 2008 as we believe you will be hearing much more about this Java-flavored web-framework.

I’ve still been working with Groovy Builders in my free time lately. With quite a bit of help from Andres Almiray to refactor my builder example to use Groovy’s FactoryBuilderSupport, ObjectGraphBuilder was contributed to Groovy core about a month ago. That’s pretty exciting news around here: Groovy 1.1 will contain ObjectGraphBuilder. Many thanks to Andres for making that a reality.

In addition, a couple weeks ago I contributed a related subclass to Grails: DomainBuilder. This does the same as ObjectGraphBuilder, but relates collections of objects following the convention used for Grails Domain classes, using ‘addTo’ methods. The plan is to commit it to subversion once Groovy 1.1 is out, so DomainBuilder will ship with Grails 1.0, which is also exciting.

I expect to use DomainBuilder quite a bit on most projects. At the very least, it will help me keep BootStrap data more readable and maintainable.

Update: DomainBuilder was committed to Grails Head this morning (December 6).

Last night’s panel discussion “The Language Debate” hosted by OTUG was fun. There was a lot of good discussion both during the panel and after the event. Charles Nutter, Robert Fischer, and Paul Cantrell were all great panelists.

One thing that often comes up in the static vs. dynamic discussion is the question of maintainability: With the lack of static typing, can future programmers look at a piece of code and understand what is happening in order to efficiently maintain that code?

My response (though I’m not sure it came off as clearly when I mentioned it last night) is that “With Power and Flexibility comes Responsibility.” That is, dynamic languages allow you to do many things that static languages typically do not. Whether to use certain features, however, is a different matter. The developer has the responsibility to make sure that the code is readable and understandable. This is why so many developers appreciate good design and the use of design patterns. When it comes to maintainability, this is no different than static languages. I have seen both beautiful and horrific code written in each type of language.

That’s why having good developers matters so much. To build good software, people need to think about what they are doing and why.

Aside from static typing, other features common to many dynamic languages also fall into this category of responsible coding. Metaprogramming is a big one often discussed lately and it wasn’t left out of the discussion last night.

My favorite quote of the night:

Code is an Information Design Problem
- Paul Cantrell discussing code aesthetics after referring to Edward Tufte

My favorite points about static vs. dynamic languages (found from one of the links on the wiki provided by OTUG before the event):

- Many programmers have used very poor statically typed languages.
- Many programmers have used dynamically typed languages very poorly.

Thanks to all at OTUG for pulling this together.