So another new process for me is only thinking about the interface design at the beginning of the project — not how I’m going to code it. Usually, I’d be thinking database schema, class diagrams, coding frameworks, etc. from the get-go. This time however, as throughout this series, I’m using Getting Real from 37Signals as my guide.
If you’ve been following along (and if not, I have a list of articles at the bottom of this post), you’ve watched as I’ve attempted to sketch out ideas for some of the most important screens in this project. This is really quite a refreshing approach and it makes a lot of sense. As Getting Real explains, the interface is what the user sees — it IS your product. We can play around with how the app is going to look and feel right NOW and not just slap it on at the end of the project.
Sketching out interfaces and changing things around to see what feels right is a ton easier than rewriting code. We can sketch, create some loose mockups and repeat as many times as we want for minimal cost.
From the previous post, you can see that I roughed out a couple of ideas for one of the most important tasks of this app: matching clients with donors. I want to revisit this task to determine what it is exactly that will need to be accomplished on this screen. Then we will rough out another interface.
There are a few of different ways a user would want to approach the matching activity:
Call up the clients waiting to be matched and find donors for them
Call up the donors waiting to be matched and find clients for them
Call up a specific client or donor and find available matches or remove assigned matches
Items 1 and 2 are just reciprocals. You either want to approach the matches from the clients’ or donors’ sides. Item 3 addresses organizations who are tracking possibly hundreds of clients and donors, who want to quickly locate a specific entity.
After a client or donor has been selected from a list or a search, the next screen would show possibly more detail about the selected entity with a list of possible entities to be matched with. At that point, a match can be made. So our screen list for this activity looks like this:
Part of the goal of this phase is to answer the following question for each screen: “How do I know when it’s useful?” So for the matching activity, let’s take it one screen at a time.
Client List Screen
At this point, I’ve decided not to put the client and donor lists on the same screen. There is just too much information for both entities to be able to make informed matches from summary displays. (I’m not trying to think of too much detail here, but I know that according to the organization, some donors may specify things like, “I only want to give give gifts to children under 10”, and things like that. Details like those do not lend themselves to summary screens.)
So how will we know when this screen is useful?
A list of all clients waiting to be matched can be navigated easily
Enough information for each client is displayed for the user to make a decision on whether to proceed with that particular client. Generally speaking, the user will want to know the genders and ages of waiting clients.
Here is the sketch:
On the left side you can see the list of clients displaying basic information: the family name (since clients are grouped by family as per a typical application), and the gender and age of each individual. Also shown beneath each individual is an indication of their current gift status. Above the list is a filter bar, where the user can set the list to display only certain ages, genders, or other criteria. A scrollbar is also available to the right. So I think this interface could satisfy the two requirements: navigate the list easily and see enough information at a glance to proceed.
The right section of the screen displays detailed information about the selected client before proceeding to find a matching donor.
Donor List Screen
The donor list screen is similar to the client list in layout. However, the summary information displayed for a donor is slightly different. For each donor, described is any specifically requested criteria about who they wish to give to (teenagers, single moms, families of 4 or less, etc.) and how many openings they have left for each type.
So how will we know when this screen is useful?
A list of donors waiting to be matched can be navigated easily
Enough information for each donor is displayed for the user to make a decision on whether to proceed with that particular donor. Generally speaking, the user will want to know the types of clients the donor is looking for and how many.
I’m not sure if the search demands its own screen (a nice big and bold search box with some suggestions perhaps) or a search box will simply sit in the right section, at the top of both the client list and donor list screens.
After a client or donor is selected to proceed from one of their respective screens, it is time to match them up. Let’s look at a concept for the screen that would display after we’ve selected a client from the client list screen.
So how will we know when this screen is useful?
A detailed view of the selected client is available
A list of available donors is easily navigated
A detailed view of a donor ready to be matched is available
A match is able to be made
Here is the sketch:
The client is the main focal point of this screen with a view similar to that of the client list screen. Immediately to the right, however, is more information about the client. Below the main client view is a list of available donors. These donors all have openings for the entire client family. (I need to think about allowing the selection of one member of a client family at a time here, but that can wait). Each donor row displays summary information for the donor — mainly stats on what type of client they would like to donate too and how many openings they have left. Immediately to the right of the donors is a detailed view of the highlighted donor. If the user is satisfied with the pairing, the match button is clicked. (I’m also thinking of dragging individual client family members down to the openings in the donor rows to make the match).
So this was more sketching, like the previous post, but I put a little more thought behind it this time. “From Idea to Implementation”, from Getting Real by 37Signals, suggests answering questions like “What does this app need to do?” and “How will we know when it’s useful?” that I tried to address this time around.
As you may recall from the last post, we’ve done a little brainstorming, and now it’s time to sketch out our ideas for the interface. We don’t want to draw details. The goal here is to just get our brainstorms on paper. 37signals suggests using big writing utensils, like markers, to force yourself away from the details. We should just be sketching boxes and shapes to convey our rough interfaces to someone else.
Before I refreshed myself with Getting Real, this is what one of my interface sketches looked like:
Notice how many details I tried to think through here. I tried to plan the exact buttons that would be needed, how a user would navigate through a list, what data would populate a section, and the details of a pop-up box. This was getting way too far ahead of myself. I had the potential of locking myself into an interface before I knew everything I needed. Plus, I used color. I actually wrote another post a while ago where I declared the joy I found in brainstorming with colored pencils. I think that may still have its place, but it should be reserved for further along in this process.
So for this exercise, I stuck to a medium size drawing utensil, and only labeled something in the sketch when it would be hard to remember later what I was actually sketching.
One of the main activities of the charity tree app is to match clients with donors. This first sketch’s intention is to portray a move away from what may be normally thought of in a data matching scenario. The easy, but boring way to implement it would be to have two list boxes, side-by-side, and the user selects data from one box and moves it to the other. Here, I thought of a view of a donor who has openings for more clients. The clients are listed at the top of the screen along with some summary data. The icon for the family is perhaps dragged and dropped into one of the donor’s open spots. This would definitely make the data much more interesting to view and manipulate than dull list boxes or spreadsheet views.
This next sketch explores a slightly different design on making the matches. Here I was thinking about interlocking clients and donors like snapping pieces of a puzzle together.
One of the other key tasks the app needs to accommodate is tracking gifts. This sketch shows an idea of looking at a specific donor, along with the clients that have been assigned to the donor, and a visual indication on the status of each gift (e.g. gifting tag sent, gift received, gift delivered). There could be a summary box at the bottom of the page displaying data such as total gifts assigned versus gifts received. Again, the details weren’t thought of too much at this point; I just wanted to portray a fun interface for manipulating the data.
Assuming we are satisfied with these sketches, we can move onto the mockups. But remember! We are not locked into the design at all. This process is about quick design iterations before we commit to the hardcore coding.
Continuing on with fleshing out my idea, we are going to look at “From Idea to Implementation” from Getting Real. This process will span several posts as we brainstorm, sketch, mockup and code.
Brainstorming is about ignoring the details and looking at the product from a bird’s eye view. Let’s just think about what the app is going to do at a high level. Too many times we can get wrapped up in things like, “How am I going to accomplish this part?” and “Do I know how to do what I’m thinking?” Forget about that and just focus on the end user experience.
Here is what this app going to do:
Accept applications from clients and donors
Match clients with donors
Create and send gifting cards
I have more ideas and more details, but they can wait. If the app doesn’t accomplish these four things, it will not be useful. We will be using this list along with the points made in “What’s the Big Idea?” to make sure we stay on track.
As noted in the introduction to this series, I will be trying to follow the guidelines laid out by 37signals, in their fine book, Getting Real. Recently, I’ve begun to take notes in my Moleskine, on some of their essays, and will share them in these articles. These notes just scratch the surface, so I highly encourage you to read the book, that you may learn as much from them as possible.
The first guideline I will address is “What’s the Big Idea?”, where we push away all of the details until later and get to the heart of the matter. What is the purpose of this app?
Define the one point vision
Manage a charity tree program with ease.
Why does it exist?
Software that handles programs specifically of this type have not been found. Charity tree programs generate a lot of data which is typically tracked with paper and pencil or unorganized documents and spreadsheets.
What does this app stand for?
This app will give charity workers, typically volunteers, the tools necessary to easily manage their charity tree programs.
What makes it different?
Typical, boring, spreadsheet-like tools will not be present in this app. Users will be able to quickly view and manipulate the data that is important to them.
Stay true to the vision
During this project, any feature being considered will have to hold up to the answers given above.
I developed a prototype web app for a charity organization a few years ago that was meant to give the administrators and volunteers control of their charity data through software, versus the traditional paper and pencil method. This project never took off, in part due to conflicting goals within the organization, lack of communication and most of all, my lack of experience at that time for maintaining a project capable of producing a reliable product and which could weather the storms of continual client change requests.
Times have changed, I have more experience, and I’ve been influenced by many great developers. I’ve been aching to take what I’ve learned and apply it to a product development project. I’ve decided that the charity project is a prime candidate for testing my new skills and ideas. The project started as a one-off, tailored-to-a-client application. I am changing the direction of the project to delivering a product that will work for many charity organizations dealing with the same types of issues.
What is a Charity Tree?
This project addresses “charity tree” programs run by charity organizations. These programs, usually run during the Christmas season, identify persons and families that are in need of help, then match them up anonymously with donors.
Many churches run internal programs of this type, where things like ornament tags are placed on a Christmas tree with ideas for gifts for a certain type of individual. A donor then takes a tag off the tree and will purchase a gift for the unknown individual. Behind the scenes, people are keeping track of who the recipients and donors are, which gifts have been delivered and a myriad of other details.
A charity organization will run the same type of program, except the number of applicants may be much larger and they may have other requirements as well, such as reporting some of their data to another organization. The people I worked with still did all of this pretty much by hand, which required an enormous amount of volunteer hours. The following tasks are an idea of what is involved in such a program:
Accept client and donor applications
Edit and follow up on applications
Match donors to clients based on several criteria
Track gifts outstanding, received and delivered
Send anonymous gifting cards to donors
Send reports to other organizations
The resulting product will be a web application that gives people within the organization easy control over the charity tree data. I envision an installable application (like WordPress) that will live on a web host.
Clients and donors will log in to fill out applications. Those without access to the web can turn in paper applications to the charity, at which time a volunteer could enter the application into the system.
Application users will have varying levels of access to the data including creating and editing of applications, matching clients to donors, tracking gifts, etc.
The goal of this software is to provide charities with an easy way to manage their program while being fun to use at the same time.
The guiding principles for the project are laid out in the fantastic book, Getting Real, by 37signals. My intentions are to follow their advice as close as I can. Two of the main objectives are:
Keep the application simple
Make the users happy
I will be posting progress on the project here and sharing my processes as I strive for these two goals.
Back in 2007, Coca-Cola held a contest to see who could design the best virtual Coca-Cola machine for their corporate presence in the world of Second Life. I had only dabbled in that world, but I’m a Coca-Cola addict and I thought it was a fun idea.
Coke wanted entries to capture the essence of the brand: refreshment, joy, unity and experience. So I set to brainstorming for a machine that would encompass those ideals. Using RayDream3D (I hadn’t used Blender much yet) and Paint Shop Pro, I created a storyboard to convey my vision.
I have been working on migrating a client from PayPal’s Website Payments Standard to Website Payments Pro, so they could begin handling purchases on their own website. PayPal and their corresponding developer network at http://www.x.com are loaded with documentation on how to use their APIs and test your code in the sandbox, before going live.
While this wealth of documentation is certainly welcome, their seems to be no clear path on which APIs you are to use in certain situations and how you are supposed to configure your code, depending on the PayPal plan you are currently under. As an example, I was referencing the wrong API documentation, well within my project, before I came across a forum post that said my code would not work unless I signed up for a more expensive plan that included access to that API.
Specifically, I was setting up my client to handle recurring payments using the Website Payments Pro plan. After a semmingly endless number of errors and wrong turns (no thanks to the confusing documentation), I finally received a successful response after transmitting a test transaction. With that, I would like to share here, the steps necessary to make this happen. I will not walk you through EVERY step, but point out the major steps and pitfalls that are not necessarily covered in the documentation.
4. Enter business information on the next page. Here are some key entries that you are unaware of unless you dig. Thanks to this document at https://www.x.com/docs/DOC-1603 for these tips
For the social security number, enter 111-NN-NNNN where N is a random number. Do not use all 1s
Select “Individual” for ownership type, “Arts, crafts, and collectibles” for business and “Antiques” for business subcategory
5. Select both fraud protection and recurring payments on the product selection page.
6. For the credit card information, you wall want to note the generated credit card number for later use. Select an expiration date in the future and 123 as the security code.
7. Confirm your email by checking your test account’s inbox (located on your developer.paypal.com page)
8. In your test account, click the “Get Verified” link and setup your bank by entering a fake bank name. When asked to confirm by entering two deposit amounts, enter a random amount between .01 and .99.
Your test account is now setup. Here are two other items to note.
1. When you begin making calls to the PayPal API, you will need to pass in your API credentials. To get these credentials, login to your test account and click the Profile tab. Click the “Request API Credentials” link. Select Option 1 – PayPal API, Setup API credentials. Select View API Certificate. Your API username, password and signature will then be displayed.
2. The documentation gives you a bunch of test credit card numbers to use, such as 4111111111111111 for Visa. They don’t work. Instead, login to your developer account and click the “Credit Cards” link under your Profile. Add a new card and note the number, expiration date and security code.
I hope this helps some of you PayPal developers out there.
I’ve always favored the trusty pencil and paper when first sketching out all kinds of ideas, and user interfaces are no exception. Visio-type tools come in handy for diagramming architecture and logic, but when visual creativity is needed, the pencil allows you to be much more loose and free-form. I was inspired recently by a video of Adaptive Path as they brainstormed user interfaces for an iPhone application. The designer used colored pencils and the sketches are gorgeous.
I am currently working on a web application for a volunteer organization, so I decided to break out my colored pencils and start sketching. I loved how it felt. The argument from many people will be, “adding color can lead you into too much focus on details when they’re not yet needed.” While that may be true, I wasn’t really thinking about bringing these colors into my final palette. I was just using them to add fun to the process of brainstorming.
TortoiseSVN, a subversion client for Windows, is used for version control. It is open source and highly regarded in the programming community. You can use it for just about any kind of project, but the most popular is for controlling source code. You can find out more about it at http://tortoisesvn.tigris.org/.
Using TortoiseSVN is incredibly easy, but people first starting out may find that the myriad of options can be overwhelming. TortoiseSVN does have a simple interface, but you will quickly realize that there are several methods available to carry out similar tasks. After piecing together bits of the official documentation and unofficial videos, I finally settled on a method that works for me.
Even more bewildering, especially if you are new to this process, is how to place an existing project under version control. I will specifically describe how I handle that, and will describe how I set up a repository and working folder to maintain my files on a daily basis.
Step One – Create the Repository
The repository is where your master files are kept — where files will be checked in and out of. Simply create a normal Windows folder, anywhere. We will call ours “My Project Repo”. Then right-click the folder for the context menu and select TortoiseSVN | Create repository here. You will then get a confirmation that the repository was successfully created. From now on, you will never treat this folder as a normal Windows folder.
Step Two – Import the files
Since we have an existing project, we will now import our project files into the repository. You will want to choose your highest level folder in your project hierarchy to import. We will be placing a Visual Studio project (called CampaignMonitorTest) under version control, so we will want to choose the folder in the main Visual Studio/Projects folder. (I realize that there is a VS plugin for TortoiseSVN, but I wanted to stay away from that for now).
To import the project folder into the repository, open the repository browser by right-clicking the My Project Repo folder and selecting TortoiseSVN | Repo-browser. A window will display the contents of your repository. Right now it is empty.
Right-click in the file area of the repo browser window and select TortoiseSVN | Add folder.
In the next window, navigate to your project folder and select OK. Enter a log message in the pop-up window, such as “initial import of project folder”. TortoiseSVN will then import your entire project. You can navigate your folder structure in the browser, just as you would in Windows explorer.
Step Three – Checkout a Working Copy
Your SVN folder is currently holding version 1 of your project, but your Visual Studio project folder has no connection with version control whatsoever. To remedy that, let’s first delete the Visual Studio project files from the project folder (this is the actual project folder in your Visual Studio hierarchy. If this seems scary at first, make a backup of your project files first). Now, checkout a working copy of your repository to the Visual Studio/Projects/CampaignMonitorTest folder by first right-clicking the top-level folder in the repo browser and selecting Checkout.
In the next window, navigate to your Visual Studio/Projects/CampaignMonitorTest folder for the Checkout directory.
After clicking OK, TortoiseSVN will checkout a working copy of your project. You will see that you are currently at revision 1.
If you look at your working copy, inside the Visual Studio hierarchy, you will see your project folder with an icon overlay, indicating that your project is currently under version control, and is up-to-date.
Step Four – Ignore Unnecessary Files
There are a few things inside our project folder though that we don’t necessarily want versioned. For example, the files inside the obj folder are automatically created upon project compilation, so we don’t need to include those. In TortoiseSVN, we simply add that folder to the ignore list by right-clicking the folder and selecting TortoiseSVN | Delete and add to ignore list. You will then see a new icon overlay, indicating that the folder is marked for deletion (not from your file system, mind you, but from version control).
Step Five – Commit Files
Up in the Visual Studio/Projects folder, you will notice the CampaignMonitorTest folder is indicating that files within it have been modified and not yet committed back to the repository (this will normally be caused by your modifications to the code, but right now it is because we marked a folder for deletion).
Right-click the folder and select SVN Commit… Enter a log message and click OK. You will then see that your files are at revision 2.
You will now notice in your Visual Studio/Projects folder that all of your versioned files display the overlay indicating that they are up-to-date. You will also notice that the obj folder has a new overlay, indicating that it is currently being ignored by version control, as you requested.