I’ve updated the tutorial on how to install ImageMagick from source on OS X, with links to the latest libraries and commands updated to reflect some changes for Leopard.
Archive for the 'Software' Category
Writing web applications for almost 10 years, I can’t count how many admin tools I’ve written. Having worked on so many, I’ve developed a programming pattern for creating them. However almost every time I make a new one, I find myself trying a new layout and navigation style.
Frequently I look at GoPlan, Basecamp and Wordpress (3 tools I also use quite often) and notice how similar their layouts are. Is this because they are doing the right thing? Or is it because they are lazy and copied each other? Should I be modeling my admin tool layouts like theirs? As a developer, I don’t have as much time to think about those things. I’m too busy making the tool work.
I am curious why so much time is spent by designers creating the front-end of a web site, but it’s usually up to the developers to create the layout for the admin tool. The usability and design of admin tool should be just as important as the public facing web site. An admin tool should be a continuation of the site look and feel, but in my experience it looks like a completely different site.
Some people say I have fairly good design sensibility. However I am not as good as a lot of designers who do it full time. This probably applies to most web developers. So next time you’re involved in creating a web site with an admin tool, consider asking the designer for at least a simple layout and style guide for the admin. They don’t have to create a design for every page, just a mockup of a sample layout that shows all types of form fields with labels, typography treatment and a navigation system. It will make a developers life much easier.
What is your experience as either a user or developer of an admin tool? What works and what doesn’t?
Recently I started riding the bus again full time…if not to save the environment, but to save my nerves from dealing with traffic. After a few days I was reminded about one of the things that bothered me about riding the bus: I hated not knowing exactly when the next bus was going to arrive.
This time around I have my iPhone, so I am able to use the tracker on Trimet.org to see when the next bus came. Except it was really difficult to use on such a small screen. I was able to find out when the next bus came, it took me 2-3 minutes to do it.
So I decided I was going to write an iPhone app to do the same thing, but with a much simpler and easier to use interface. At first I was just going to scrape the Trimet site to get the information. But then I came to find out that Trimet actually has a really nice API to all their tracking information!
So I present to to you the Trimet Tracker, an iPhone app that allows you to easily find out when the next bus is going to arrive at your stop. Just enter your Stop ID and you’ll get a list of all the arriving buses (or MAX or Street Car), what time they will be showing up, and how long you have to wait. If you don’t know your Stop ID, you can also do a quick search by picking a route and selecting from all the stops on that route.
To make it even easier, you can also save any stop to your favorites list so you don’t have to enter a Stop ID or search for your stop again. Just hit ‘Favorites’ and select which stop you saved.
Obviously this tool isn’t for the masses…how many people are riding Trimet with an iPhone? Even if no one uses it, this tool has already saved me the a couple times from missing a bus. That’s worth the whole 4 hours it took me to develop it.
For the technically inclined, Trimet Tracker was built using the Camping microframework, IUI for the interface, and a few lines of custom Javascript.
One final thought: I now firmly believe that Portland is the geekiest city on the west coast. Even our transit system has an API.
I finished a quick app for the iPhone that allows you to do a whois lookup on a domain to see if it’s available or not. I’m always out and about and think of a domain name, and want to know if it’s taken.
Why don’t you just use whois.net or something, you ask? Well first of all that site is packed full of bloat and junk that makes it a pain to look something up. Secondly, I have a sneaking suspicion that sites like whois.net harvest requests and register those domains if no one else does. And no, my app does not record lookups!
I built the app using a small PHP script and IUI. Check out the app at http://whois.onmyiphone.net
Before the iPhone came out there was the announcement: the official SDK to make applications on the iPhone was HTML and Javascript, displayed in a web browser. I read a lot of comments complaining about that, programmers that wanted real hooks into the iPhone system. For instance, you can’t access the phone’s address book, voice mail, or photos with a web browser.
But I think Apple made a smart move. Making a web browser the official software platform allowed many more applications to be developed in a really short amount of time, since a lot more people can make web apps than can create native applications for OS X. And since a web browser is already the defacto communications conductor on the Internet, integrating the phone with information on the Internet is already done.
Why do I love developing for the iPhone?
- I get a fixed screen size. It’s almost like designing for print again. I get 320×480 to work with on my web app, and I can bet that won’t change for quite a long time. No more designing to work within a range of resolutions, I know my app will fit in the screen as I intended. It also forces me to be creative with the space I have, which is a refreshing coming from developing for desktop browsers.
- I only have to code for one browser. Actually, the best part is I don’t have to code for Internet Explorer. I know my site will render exactly as I wanted it to when I originally made it. The CSS will render predictably, and the Javascript will work like I planned. Also, Safari on the iPhone is a full-fledged browser that can do just about everything a desktop browser can do, not some crippled smartphone browser.
- It makes me think differently about user interfaces. The only time I’ve developed for a touch screen was for a small kiosk project that lived in a museum. Most people don’t have the opportunity to develop a site that will be used with your fingers. It changes your perspective on designing web applications when you don’t have the typical mouse and keyboard setup. It gave me ideas and inspiration to take with me back to the desktop world.
- It opens up a whole new range of applications. Ideas that were pretty good on the desktop are now more useful than ever. Location-based searching and apps like to-do lists and mileage logs make a lot more sense when the user can have it with them all the time, and not tied down to a desktop.
I have a feeling Apple will eventually open up the iPhone to allow developers to create native applications, but the web browser based SDK will probably stay the most popular. If I could develop iPhone web apps exclusively, I would. It would be so much more fun.