One Month App

Technical Wrap-Up

Stephen Rainey — Sun Nov 04 00:00:00 UTC 2007

We launched Pulse on October 24th, on schedule, albeit a little later in the day than we expected. One of the main reasons we did this app was to blog about the process and get some discussion going with our colleagues. This worked out pretty good but you did not hear as much from the technical side as you should of. This is definitely something we will do better if we do something like this again.

We chose September 24th through October 24th because we were balancing a lot of projects on the front end and I had a much needed shoulder surgery planned afterwards. We were wanting to do this application early in the fall, so that we could spend some focused time on Reflect through the end of the year and the beginning of the next.

This timeframe seemed to be pretty good especially considering that both Nate and I would be programming and the application should not really take a month program if we are sticking to our goals, but things don't always work out the way we plan.

Nate ended up not being able to program on the project at all due to other projects that we were involved with. These projects ended up taking a good chunk of my time as well. Needless to say a lot of this project was programmed in the last week and a half of our timeframe but everything came together nicely and on schedule.

Deployment and Launch Day

Our server was graciously donated by Global IP Networks which is a new venture from the same guys involved with Globalcon.net. We received our server about a week before the planned launch date. At that point I went ahead and installed a little bit of the production environment just to make sure everything was functioning properly.

When launch day came around, I had a number of items on my plate. These were to finish up a punch-list that Aaron had put on Basecamp, implement a few more features, finalize the production environment, and finally launch. I had already completed and tested my DNS changes because we were using a brand new domain name.

The punch-list included mostly straight forward items as well as a javascript issue that we had found the night before. The javascript issue was a major issue because it basically broke the adding and editing of payments. I can deal with most javascript issues but I was not sure of an immediate course of action for this problem. I made a gamble and went to sleep at a normal hour in hopes that a fresh and rested mind would solve the problem quicker. This gamble worked out great and I was soon to my other items early in the morning.

First I finished the punch-list and then I tackled the server setup. Things were wrapping up nicely, so we decided to work on another feature that we could slip in before launch. While the feature worked, we spent a few more hours on it than we wanted and there were also a few small issues with it that made us uncomfortable. Despite the time we put into it we decided it would be best to add this feature at a later time.

We decided to start pushing everything live at about 3:30 in the afternoon. At first everything seemed to work great, but then we noticed an issue with how the app scrolled through the months. This was not very fun because it was only an issue on the production server. Everything worked great on our development server as well as our local machines.This issue eluded me for many more hours than I would like to admit, but I was thankful that I had rested well the night before because otherwise my mind would have been clouded by both tiredness and rage.

Finally we launched the application. We then monitored it as people signed up and pushed a few more tweaks live.

New Features and Tweaks

We still have some new features and tweaks in the works. They will be coming after we get some good user feedback and have adequate time to implement them. We would love to hear any ideas that you may have that could make the application better.

Pulse is launching today!

Aaron Boeving — Wed Oct 24 00:00:00 UTC 2007

We're putting some finishing touches on Pulse and will be launching later on today. Enter your email address in the form on the sidebar and we'll email you as soon as we launch.

Stay tuned!

The One Month App has launched!

Aaron Boeving — Wed Oct 24 00:00:00 UTC 2007

We're very pleased to announce that the One Month App is finished, and Pulse has arrived. Go check it out:

pulseapp.com

So, what is Pulse?

Pulse is a web-based cash flow management tool that allows you to easily monitor the heartbeat of your small business -- your cash. Say goodbye to unmanageable spreadsheets, and hello to an intuitive interface with the power to quickly manage and evaluate your income and expenses. Pulse makes tracking the health of your business simple, accurate and efficient.

20 tools for web application development

Stephen Rainey — Sun Oct 21 00:00:00 UTC 2007

One of the main reasons we started the One Month App is because people always seem to be interested in our development process. One of the aspects of our development process is naturally the software and tools we use. The following is a list of the tools that we have used on this project and others, covering our full technology stack that includes desktop, hosted and server applications. We would be very interested to hear about any tools that you use in your development process as well.

Ruby On Rails

Rails is an open-source web application framework that is geared towards developer happiness and sustainable productivity. This is currently our preferred framework and we have been using it for the past couple of years.

Textmate

Textmate is a text editor for Mac OS X. I found this editor a few years ago. Soon after that, I started seeing it used in a lot of screencasts that showcased various web development technologies. It appears like a simple editor, but it packs a lot of useful features under the hood.

Skedit

Skedit is another text editor for Mac OS X. We'd argue that Skedit is more designer friendly than Textmate because some of it's default features sets such as special characters helpers and remote file capability. Skedit makes writing clean markup a breeze for a web designer.

Adobe Creative Suite

A standard suite of software for any designer, we use Adobe Creative Suite for everything from design mockups to slicing up graphics for the web.

SnapNDrag

A very simple piece of software for Mac OS X that allows you to take screen captures and simply drag them from the software to another piece of software (such as Adobe Photoshop). This is great when you are considering a UI change and you want to take a quick screenshot, pull it into Photoshop, and make a quick mock-up.

Parallels

Parallels is an essential tool for allowing cross platform/browser development. We use this as we are testing our web applications in various web browsers and platforms.

Firebug

Firebug is a plug-in for Firefox that has many web development tools. The main use that I have for it is the inspect feature. This allows me to inspect the HTML at any time including after AJAX calls have taken place.

Basecamp

We use Basecamp to communicate and collaborate on all of our projects. It allows us to set up a schedule with milestones and keep our messages and to-dos all in one spot.

Lighthouse

Lighthouse was developed by our friends at Active Reload. It's a reasonably priced web based hosted tool for dealing with bug/issue tracking in software projects.

Subversion

Subversion is an open-source revision control system. I'm not really sure how we developed websites without using subversion in the past. What I do know is that I do not want to go back. Not only does subversion keep track of our revisions and protects us while multiple people are working on the same things, but it is also the reason that I hardly ever open up an FTP client. Sorry Transmit, I still love you.

Warehouse

Warehouse was also developed by Active Reload. It is a web based tool that lets you browse through your subversion repositories. Unlike Lighthouse, you can install this software on a server of your choice.

Terminal

Terminal is my second most used application. I use it while working in my local environment as well as interfacing with our servers. I have always liked Linux over Windows, but I felt that some of the user experience was a bit lacking. When OSX came around with its BSD foundation a lot of us web developers started making the switch. It has great user experience, but you can open up the terminal and feel at home.

Incubator

I found this great piece of software about 3 years ago when it was known as pyramid. We use it for all sorts of various tasks that require organizing thoughts.

SQLEditor

I have been lightly searching for a simple Entity Relationship Diagram (ERD) tool that was native to OSX for the past few years. This is a tool that I found when I started this project. It certainly fits what I am looking for.

MySQL

MySQL is an open-source database that we use for most of our web applications. Another great package that we occasionally use is PostgreSQL.

MySQL Query Browser

MySQL Query Browser is a GUI application to help you take a quick glance at your queries. With features that allow you to save and bookmark queries, as well as built-in documentation on the available features of MySQL, this tool makes developing and working with schemas an easy process.

Linux

Linux has been my preferred server operating system for nearly a decade or as long as I've been developing web applications. All of the tools that I use are at home on this platform.

Mongrel & Mongrel Cluster

Mongrel is a fast HTTP server for Ruby applications. Mongrel Cluster is a GemPlugin that wraps the mongrel HTTP server and simplifies the deployment of web applications using a cluster of Mongrel servers. Mongrel Cluster will conveniently configure and control several Mongrel servers, or groups of Mongrel servers, which are then load balanced using a reverse proxy solution.

Nginx

Nginx is a lightweight HTTP server that we use as a reverse proxy for our Mongrel Cluster. It also serves up our static and cached files.

Monit

Monit is a utility for managing and monitoring, processes, files, directories and devices on a UNIX system. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations. We mostly use monit to keep track of our Mongrel processes. If one fails or starts using too much ram, it will automatically restart it.

One Month App gets a name and logo

Aaron Boeving — Wed Oct 17 00:00:00 UTC 2007

After much deliberation, we've decided on the name Pulse for our cash flow management tool. And here's the new logo:

Although there were some excellent (and quite funny) suggestions from our post the other day, we felt that Pulse mostly clearly defined what we are trying to do with this application both now and in the future. We think cash flow management is about tracking the pulse and vital signs of your small business. In addition, we've got some potential new features in mind (for the future) that would make this application as much about business health tracking as it is cash flow. The logo concept is simple and effective. By making the letter "l" of the word Pulse into a rhythmic graphic, the idea clearly shines through.

So, let us know what you think. We hope you like it as much as we do.

While Stephen and Nate are finishing up the programming for the app (more posts from them are coming soon, I promise!), I'll be jumping into developing a simple promotional and signup website for Pulse. Things are really heating up.

Technical Update

Stephen Rainey — Wed Oct 17 00:00:00 UTC 2007

The application itself is coming along nicely. As always, it has been quite a struggle to focus on a venture of our own while maintaining client projects. Nate has not been able to work on this project as much as any of us would like, however he is giving great input and he will be able to focus on some of the marketing efforts after the month is up.

I generally start a new Rails project with just enough in there for Aaron to be able to mock up each of the screens. This means that after I completed my database design I moved right into stubbing out the application framework even further with my new models and test data. After that I decided to tackle the users/account and authentication first. Although most design is done prior to programming, Aaron typically styles the login, signup and related screens after this is in place.

I am currently completing the main cash flow or "worksheet" screen. I will be adding the Basecamp integration next and then I will finish out some of the smaller supporting screens.

In my next update I will be discussing some of the tools and technologies that we are using for this application.

Help us name the one month app

Aaron Boeving — Mon Oct 15 00:00:00 UTC 2007

In a perfect world, with perfect timelines and perfect budgets, we'd hire a branding agency to help us devise the perfect name and branding for the one month app. That perfect world definitely does not exist in this short month, so we are tasked with coming up with a name and giving it some kind of brand. And to be honest, we'd really like your help. So, if you're willing to throw out a name or two (without any strings attached), then post a comment with your best idea(s). To get things rolling, we've been brainstorming words, ideas and potential names:

Cashwatch, Cashtrack, Moneytrack, Racetrack, Cashline, Cashway, Pulse, Cadence, profit, prosper, flourish, thrive, metric, advance, manage, cascade, Cashmeter, Flowtrack, Trackflow, Flowmetric, Traction, Fit, FitMetric, Trim, Cultivate, cash cow, CashMetric, CashGlance

On a side note, we don't have to have the "dot com" but a catchy domain to go along with the name is always a plus.

Update: We've chosen "Pulse" as the name.

Using tbodys for javascript hooks

Aaron Boeving — Thu Oct 11 00:00:00 UTC 2007

When writing the markup for the main cash flow chart, I knew that it was going to involve tables to make everything line up well while keeping the fluidity of the layout. That in of itself is a simple thing to do of course, but I also wanted to provide a certain layer of organization that made the javascript work simply. Here's a quick tip in using tbodys to provide hooks for javascript.

In the design there are groups of table rows that need to be targeted to expand and collapse the content. In a normal situation, I would wrap a div around whatever I was wanting to show/hide or toggle and use the prototype library to target it with a javascript effect. However, wrapping a div around table rows doesn't work in keeping with semantic markup. In comes the tbody. I created a "income" tbody and an "expenses" tbody to provide the hooks for the javascript. Take a look at this video to see the javascript effect in action.

Database Design

Stephen Rainey — Tue Oct 09 00:00:00 UTC 2007

One of our first real technical tasks is database design. While some of this is in the back of our minds though the initial stages, it becomes more important as we start to nail down the front end interface. This is the point where we make sure everything that has been designed is taken care of from a data standpoint.

We also focus on the future scalability of the application. For instance, although we will not be allowing multiple worksheets in the initial application, we have created a table for this to tie all data to a particular worksheet from the get go. This will allow for easier implementation in the future if we choose to add this feature. At the same time, it is important to not focus too much on the future as you risk causing yourself a lot of problems for things that may never happen or could be dealt with easier down the road - be sensible.

One of the things I wanted to do on this website was share some of the tools that we use. For years I have been searching for a good and simple Entity Relationship Diagram (ERD) tool for OSX. I do not have the desire to use these for every project, but I do find them useful at the beginning of projects. Last week I came across SQLEditor. I have been trying it out on this project and it seems to be about what I have been looking for.

I completed the initial database design at the end of last week and have since moved on to the actual programming. I will post more on that soon.

Simplifying the interface

Aaron Boeving — Wed Oct 03 00:00:00 UTC 2007

As I started to build out the initial design mockup into HTML/CSS, I realized that I was going to need to simplify a few things in order to accomplish everything I wanted to do with the interface. I wanted the interface to have a flexible width to accommodate different screen resolutions but mainly to give room for cash flow charts with big numbers and longer income and expenses titles. In deciding upon a flexible width, I realized in order to so with the rounded corners and gradient background, I was going to have to have a ridiculous amount of markup. Also, to be honest, in order to make the layout "bulletproof" I'm not even sure it would be possible. (If anyone wants to try, I'll gladly provide the PSD file.) Here's a screenshot of the revised interface buildout.

From the above graphic, you'll notice that we got rid of the rounded corners, and I shortened the gradient background to just the header. This gave a much cleaner look while making the markup just a mere few lines for the main template:

The layout did loose some prettiness, but I think with the simplification of the interface and markup it was worth it. What do you think?

Next up, I plan on writing a post on some of the finer details of the markup in regards to the main cash flow chart. I had to freshen up my knowledge of tables on this one!

Technical Roles in the Design Stage

Stephen Rainey — Sat Sep 29 00:00:00 UTC 2007

We are currently 6 days into this little venture and it appears that Aaron is doing all of the work. While this is mostly true, Nate and I do have a few responsibilities at this point.

We initially helped Aaron brainstorm and come up with the initial requirements. We basically talked through how we thought everything would work. I honestly do not really know how things are going to shape up until I start seeing some of Aaron's mockups, so we send him on his way to start creating the initial visual elements. When he gets good and ready, he will show us the mockups he has been working on. Anyone who has worked with a designer knows that this is the point where you listen to about 10 minutes worth of disclaimers before you actually get to see anything. We've actually cut those disclaimers down a bit in our recent work.

Aaron showed us the initial design mockup a few days ago. This is the point where it becomes more real for us. We can see how the user is actually going to interact with the application. This helps us identify any missing pieces as well as expand upon our existing ideas.

A less technical aspect that we all work on while reviewing the design comps is to think through the end user aspect. The end user is our ultimate concern and we each have different perspectives and identify different concerns.

We are also considering how all the technical pieces will come together. Sometimes we can make slight alterations to the design that will not affect the end user, but will save us time in development or even utilize less system resources once the application is running. This is of particular concern because we will be offering this application for free, which does not leave much in the budget for big beefy server clusters.

So to recap, this is what Nate and I have been working on:

Brainstorming ideas
Gathering initial requirements
Listening to designer disclaimers - Just kidding Aaron
Reviewing the mockups
Usability revisons
Initial technical design

You will be hearing more from Nate and I during the week as we start digging in to the data model designs.

Initial design mockup

Aaron Boeving — Fri Sep 28 00:00:00 UTC 2007

(Click to enlarge)

Take a look at this mockup of the initial design. Here's a few notes:

Sticking with the initial sketches, I've kept with the basic idea of a grid structure.
This mockup shows a simple example of what a company's cash flow could look like. It shows some fake income and expenses to give the basic idea of how things will function.
You'll notice that there is a span of months at the top giving a good range for understanding and viewing your cash flow. The arrows to the left and right will allow you to quickly scan back and forth through the months.
The top blue bar gives your cash on hand (cash at the beginning of the month) figures.
Directly below the cash on hand, you'll find your income for each month.
To help keep things organized, there will be expanding and collapsing options for the income, expenses and each company. This will be done by clicking the arrows next to each item. Currently the income is expanded and the expenses are collapsed.
When entering a new income item there will be the option to give it a potential of it actually coming in. At the top right there is slider allowing the ability to show jobs according to this potential. Slide the blue circle left and right to view the income according to its potential.
Quickly add income and expenses by clicking on each link to reveal the forms.

A few things we're still considering:

We're still considering the best way to edit a specific project's or company's income. This could be handled with a Javascript rollover that popped up an edit link to the left of the title or by simply putting an edit link next to each item.
The graphic above shows all positive cash flow. If a month has negative cash flow, we'd like to display those columns differently without being too overbearing or obnoxious.
We're also still playing with showing past, present and future months. Above, we've shown the past month (September) grayed out, and the current month highlighted in green.

So, that's the gist of the design. This mockup is still in Photoshop at this point, but my next step will be to start building out the basic layout in HTML/CSS and start digging into the different screens of the application. During the build out process things are always tweaked and refined as we get a more clear example of how things will really be functioning. We'll be sure to keep posting screenshots of our progress. We've tried to keep things simple and to the basics of what cash flow is about. We believe this is the best direction. Let us know what you think.

Design sneak peak

Aaron Boeving — Thu Sep 27 00:00:00 UTC 2007

I'm still in Photoshop working on the overall design and layout. Here's just a little section of what I've got so far. Hopefully by tomorrow it will be at a point to show the whole thing...

Sketching out ideas

Aaron Boeving — Tue Sep 25 00:00:00 UTC 2007

I started today on the initial design of the application. This mostly revolved around doing a lot of brainstorming and sketching on what it is going to look like and how it will function. To start out, I like to put a lot of emphasis on the process of how things work rather than the actual look and feel (more on that here). Because of this, I jumped right into the main section of the app which is the cash flow management, and in doing so focused on the main elements or "patterns" of this section.

In the past, Clear Function has used a simple spreadsheet to help us calculate and track our cash flow. And to be honest, it does a pretty decent job. However, problems come up in the actual management of things as far as adding new jobs, creating new months, putting in new expenses, etc. that make it not so fun to use. That's where the idea for this app came into play. We wanted something as basic as a simple spreadsheet, but as quick and easy to use as what is possible in a modern web application.

That being said, I think there is a lot to learn and a lot of design merit in the layout of a spreadsheet when it comes to looking at numbers. You'll notice in the sketches above that I'm imagining a grid structure allowing a quick glance of income and expenses over several months. I also envision being able to quickly add an income item or expense item in this spreadsheet view. I'm sure things will change over the next several days (as they always do), but for now I feel pretty good about this direction. Please leave your thoughts if you think differently.

Next up, I'll be digging into more of the look and feel of the app. This is when I'll turn sketches into Photoshop files, and Photoshop into HTML/CSS. I should have some screens to see in the next couple of days. Things are really rolling now.

Kickoff

Aaron Boeving — Mon Sep 24 00:00:00 UTC 2007

Today, we officially start the one month period. As to most things, we're gradually getting things started before we get full blown into design and development. After lunch we decided to have a quick kickoff meeting to get everyone on same page, and go over the basics of what the app is going to be. Using our favorite outlining tool, we mapped out the basic architecture of the application (see screenshot below).

As we've stated before, this application is all about simple cash flow management, and really the entire app revolves around that. If you take the most basic elements of cash flow, it revolves around Expenses and Income with other secondary functions like making them recurring items and categorizing them by client and tags. The other main areas of the application are mainly management geared more than anything else:

We'll have to figure out a quick way to add clients and projects, and we also want to make Basecamp integration extremely easy as well.
Obviously, we're gonna need Users so that the cash flow is easy to share between several people. We'll also probably need some kind of permission levels for the users.
Lastly, we'll need the typical Account settings that has your basic information and the ability to delete your account.

So, that's pretty much day one. Next up will be for myself to start digging into the design. We always start with the design of the application as it will drive how the app comes together and functions. Stephen and Nate will start into database models and getting the Rails application infrastructure in place.

Ready. Set. Go!

What is the One Month App?

Aaron Boeving — Wed Sep 19 00:00:00 UTC 2007

We don't have a name, we don't have a UI design, no programming has been written, no server infrastructure has been set up, but somehow by October 24 we plan on launching a brand new web application. One Month App is the brainchild of Clear Function in which we intend to design, develop and launch a web application in one month. The idea was inspired by three factors:

We had this great idea for a simple web app.
We wanted to get it done quickly.
We wanted to document our process.

Clear Function has developed many websites and web apps in the past for ourselves and various clients, but we've never had such a tight deadline. However, we like a challenge and feel that the short time frame and constraints will help it to become a great, simple product. We hope this blog will serve as a great resource for the ins and outs of developing a web application from concept to design to programming to deployment. This should be an exciting and stressful one month ahead and we're excited about its potential.

About the app

The app is going to be a free and simple cash flow management tool for small businesses. It's main purpose will be to simply track the cash flow related to your projects and clients (integrating with the Basecamp project management application's API). We think that cash flow should be quick and easy and often times has nothing to do with accounting, which it is often associated with. When you put on the cash flow hat, you're thinking about the overall health of your business, but also making sure that you've got enough in the bank to pay yourself and employees. It's more about business health, than detailed numbers, charts or graphs. We're developing this app because we want to use it ourselves and we think other people will want to as well.

The rules

The rules are simple. All design and development will be done during the one month time period. All hours of the night and early morning are fair game.

The team

Aaron Boeving, Designer: Aaron will be tasked with designing the user interface, building out the HTML/CSS, designing the logo and branding and creating the promotional website.
Stephen Rainey, Lead Developer: Stephen will be tasked with programming, data modeling, server infrastructure and launch.
Nate Klaiber, Developer: Nate will be also tasked with programming, data modeling, server infrastructure and launch.

The one month period will officially start on September 24 with blog entries following. We suspect that we'll be posting an entry at least every other day, but probably more. Reader participation will be a big part of this blog as we'll be asking for your opinions and advice on many areas of the design and development of both the application and the promotional website and branding. We're excited about seeing how the app ends up and we hope that you'll stay tuned and help throughout the process. This should be an interesting month.

Update:

I meant to point out in the original post that the time spent between the 3 team members won't be 100% spent on this project. At Clear Function, the majority of our time is spent working on projects for our clients, but we also schedule out time to work on our own projects and ideas. The one month app is not the only Clear Function project we have going on during this month and the majority or our time will still be spent on client work.

Also, our friends over in the DIGG world are enjoying saying that the app we are building could be done in a time span ranging from one day to a couple of weeks. While this could be true, the point of this blog and application is not to get it done in the quickest amount of time possible. The point is to put an appropriate time constraint on building a quality app and to document our process during this time.

Anyway, back to work :)