Where have I been for two months?

Obviously, I am not a dedicated blogger. Neither am I a journaler or diarist (is that even a word?) Bottom line, it's dang boring writing down every little thing. So, here is the Reader's Digest Condensed version...

February


  • Wrote a lot of code

  • Discovered that I was a little too ambitious with my html/sketches

  • Broke things apart a little more to make it easier to code but still sensible to user


March

  • Wrote more code

  • Updated Ruby on Rails, which made the whole site blow up

  • Re-setup the site about 6 times (hey, that was good practice!)

  • Made a cool logo for DocTrax

  • And, got it done!

I ran it by Pam to see if it made sense to her. Yes! So I moved it over to the production server and sent all the staff a link to it. Meanwhile, Pam set up the student staff and entered the pending documents we had out there and we were up and running!

Is she ever going to write any code?

Obviously. But, that would be jumping ahead of the process.

First, I had to run the dummy interface past the staff and get approval. It was a hit and I'm good to go with it as-is. Whew! They were really on board with keeping it simple. Either that, or they were tired out from the meeting we had before the demo.

I was ready to set up the Ruby on Rails project for the application. I typed "rails doctrax" and it was done! I love Rails.

OK, well there's a little more to it. Here's a quick overview:

  1. Had someone set up a mod_rails {Passenger) instance on the server.
  2. Set up a symlink, which points a short url to the real url, which is long and nobody will remember it.
  3. Imported the app into the svn repository and checked it out on the server and my laptop.
  4. Changed directory and file permissions so I'm not the only one who can use it.
  5. Created a new project in Textmate for working on the app.
  6. Installed rails gem 2.1.1 and froze the project.
  7. Had someone create a mysql database for the project.
  8. Set the database.yml file to use this new database.

At this point, it was ready to start doing some doctrax-specific stuff. Here is what I did:

  1. Created the Students controller.
  2. Added map.resources :student to routes.rb, so I can have a RESTful project.
  3. Created the Student model.
  4. Ran rake db:migrate to have rails create the table for me.
  5. Copied the html from my demo site into students/index and edited the form to work with Rails.
  6. Added map.root :controller => 'students' to routes.rb and deleted public/index.html so the app will automatically go to the students page on login.

With all that setup done, I was able to go to https://vcassldev.d.umn.edu/doctrax and see my first page of my app, brought to life. Aahh.


From Hiatus to HTML

With great intentions to jump right back on the project after break, the end of the week came and I hadn't worked on DocTrax at all. Sadly, I let the minutia on my to-do list rule the day. I'm blaming it on the below-zero weather and the struggle to just survive.

Then, a lucky break last Saturday...I unexpectedly found myself proctoring an exam-two hours with basically nothing to do except watch people take a test. I finished up all the paperwork I could related to the exam, which took about 10 minutes. What to do with myself? So, I sketched out the details of that last page I was struggling with for DocTrax, on the back of a packing list. Hiatus over!

The next step in the getting real process is to create html screens based off the sketches. I considered skipping this step, but didn't for a couple reasons:


  1. My pencil sketches were a little hard to read and redrawing them didn't seem all that fun.

  2. I think it will be easier for staff to review if it looks more like a web app and less like a paper slide show.

  3. I'm going to have to write the html anyway at some point. This way, I can just copy and paste it in to the rails app.

  4. I didn't want to start working on the app yet for fear of being sucked in and starting to write code, rather than sticking with this process.

A couple hours later, using Dreamweaver, I have a dummy site, ready to show to staff and get final input before I start coding.

What's in a name?

| 2 Comments

How did "Resume Tracker" become DocTrax? Well, resume tracker wasn't accurate because we need to track cover letters and personal statements also. "Document Tracker"? Pl-ease...boring!

I know how to create a new Rails project, but it needs a place to live on the server, so I went to see Alex. "What do you want to call it?" he asks.

Tracker? Too Chevy and not descriptive enough.
Doc_Tracker? Still boring and I want to avoid having an underscore in the name to make the url easier to remember for the users.
DocTrack? Good, but not cool enough.
DocTrax? Perfect.

The doctrax folder is ready and waiting for me on the development server when Christmas vacation is over.

Sketching

Step two of the getting real process is to sketch out on paper the rough interface designs. Here is where "easier said than done" came into play. I should explain that the application will require users to be set up by an administrator and then log in with their U of M x500, at which point they will land on the main page of the application.

Mistake number one: the main page. I automatically made three sections: student, staff, reports. Seemed logical, seemed like most of our other applications. Then I remembered the goal: focus on the essential-we only need to find a particular student's document. Erase the staff section. We can add that later. I also changed "reports" to just a pending report that will show all students with documents currently being reviewed, as a way to find one without having to know the student's id or x500. A generic reports link will probably appear in the future, but not right now.

The next couple pages came quickly: a new student page for entering info on students not in the database, an admin page for setting up users, and the pending report.

Once again, had to erase a couple things. Do we need to collect a student's phone number? No. Pam said we never call them, just email. Don't need it, don't add it. Do we need to have boxes for both id and x500 where you look up a student? No. The code can figure it out, so enter either one.

The hardest page turned out to be the page that shows a particular student's activity. I'm on sketch four with that one (I'm glad I didn't skip sketching and jump straight to html!) This page could get really ugly (user-unfriendly) with info, so I'm trying to strike a balance between what there is and what you really need on this page.

And, yes, there will be a staff page. But we don't need it yet, we don't know who can see it (everybody, just that person, staff but not student workers), we don't know what will be on it and we can't meet for 2 weeks.

I gotta keep this baby movin'!

Brainstorm

The first step in the getting real process is brainstorm. But, since document review is an existing process that seems to work fine, we didn't need to brainstorm. I will just reiterate that the essential function of the application is to be able to determine where a document is at any given time. No need to overthink things here.

Outside in

If you read "Getting Real", which I'm sure you have by now (or at least down to the fifth paragraph of the intro), you would discover that they advocate designing the user interface first, before you write any code that does anything. Yes, this is backward from the way web apps are usually done, which makes it even more interesting to me.

The process is: brainstorm, sketch, html screens, code.

Instead of telling the user what the application CAN do, you find out what the user WANTS the application to do. Bonus: you don't waste your time building a lot of features that never get used, just because you can.

You're going to have to build the UI anyway, so why not do it first? Let the users look at a non-working version of the application--they'll be able to tell if it's going to do the job.

Well, that's the idea anyway. I'm going to trust the process and see how it goes.

What are we doing now?

Career Services has been reviewing students' resumes, cover letters and personal statements for years, so the process is already in place. I sat down with Pam and she took me through it, from a student dropping off (or emailing) a document to picking it up. As the document moves among several people, it gets logged in a notebook.

So, step one was to determine what this web application was going to do (and not do). When it first came up, we called it "resume tracker", but should it do more? It's tempting to add fancy reports, allow comments all over the place, upload documents, etc, but I'm "getting real" here. So, the application will replace the notebook and that's it. For now.

That's all we really need at this point. Soon, several Career Peers will start helping with reviews. More people=more places a document could be. The essential function we need is to know where a document is at any given time.

Why not make it do more?


  • We want to start using this right away

  • We're not sure what else we want it to do

  • Rails makes it easy to add stuff later

Why I'm Getting Real

Before I start in on the project, a little history...

For the past year, I've been experimenting with ROWE (Results-Only Work Environment) by working at home at least one day a week, and generally trying to work smarter. So, I was reading the Cali and Jody blog to revisit the concept and get inspired. One of the entries was about how the founder of 37signals lives the ROWE mindset. Which led me to the book, "Getting Real," by 37signals, which is free on their site.

Isn't it interesting how one thing leads to another?

So what is "Getting Real"? Basically, it's a "a smaller, faster, better way to build software." Hey, that's just what I'm looking for! We need to start using this application ASAP, like Spring semester. That gives me about a month to deliver something. Yes, this is a self-imposed deadline and if I don't meet it, the world will not end, but I tend to procrastinate, so it's just better this way.

Rather than puke out a lengthy synopsis of "Getting Real", let me sum it up: Focus on the essential and get it to the users quickly.

Easier said than done? Maybe.

What I'm doing here

This is my first blog. Ever. I couldn't see myself mindlessly blogging forever about my boring life, or anybody reading it, for that matter, so I have been blogless until now. I know, I'm probably the last person on Earth without a blog. I don't text either. Anything else you need to know?

I like a good reason to do something, and an end in sight.

Career Services is in need of a better way (i.e. not in a paper notebook) to track resumes that students drop off for our counselors to review. I was looking for a project that I could write in Ruby on Rails that would be something fairly simple and that I could do mostly myself to learn a few things I've skipped over. Then, I read "Getting Real" and the whole project became something worth blogging about.

Recent Comments

  • Alex Jokela: Nice work. I like the conversational style of your writing. read more
  • jwestlun: Becky, This is AWESOME! A blog and a project, all read more

Find recent content on the main index or look in the archives to find all content.