Displaying percentages

David Stone | The Design, The Development, Amigo | Tuesday, August 15th, 2006

In Amigo we’ve got percentage bars! This was the image that Jason came up with:

In turning this part of the design into something flexible on the website I saw two options; clever CSS, or ‘Lots of Images’. I decided that ‘Lots of Images’ was a bad idea:

  • If they were generated in PHP you’ve got that extra overhead
  • For each percentage bar you’d need to download another image - extra bandwidth & slower for the user
  • Could get difficult for a designer to update (and, it’s an image after all)

… so clever CSS it is.

The Code

Okay, it’s not really that clever, it’s CSS not rocket science. It does however mean that no matter how many percentage bar’s will be displayed on the page the user will only need to wait for two images to be downloaded. I think it’s a nice solution that you might be interested in. Here’s the XHTML & CSS:

<img src="/images/percentImage.png" alt="9.5%" class="percentImage" style="background-position: -110.315px 0pt;" />

img.percentImage {
 background: white url(/images/percentImage_back.png) top left no-repeat;
 padding: 0;
 margin: 5px 0 0 0;
 background-position: 1px 0;
}

If you understand XHTML/CSS, you’ll see there’s two images involved. The first image is the border for the widget, inside of the border it’s transparent:

percentImage.png

The second image is the bar’s color, split into two halves. The first 50% is the "full" color, the remaining 50% being the "empty" color:

percentImage_back.png

What’s it doing

Notice, the alt attribute of the img tag (I’m with you Roger) is the percentage that the image represents for screen readers etc. - this is important information and we want to make sure it’s accessible!

The width of the img tag will always be the same regardless of the width of the background image we set in the CSS, knowing this we can position the background to the top left (as default) and set it not to repeat. The background-position is set to 1px so that the image fits within the border in the first image, however, we could make the image a little large if we wanted to.

The inline style handles what pecentage we want to display in the box by changing the position of the background-image. In our case a PHP script handles all the math for us (which is why it’s a little too exact, however I believe browsers will round that to the nearest pixel).

I’ll throw a few other thoughts out there for anyone interested in using this method:

  • When inline styles become redundant in the XHTML standard
  • Page Zoom (IE7) - how would that change the display of this widget

Want to be a Beta Tester?

Ryan Carson | The Team, The Development, Amigo | Thursday, June 22nd, 2006

Just head over to heyamigo.net. We’re looking for some quality testers to get involved starting next week. It’s a great chance to get a sneak peak at the app and help us make sure it’s bullet proof.

PayPal to the Rescue

Ryan Carson | Video Diaries, The Development, E-commerce, Amigo | Monday, May 29th, 2006

Amigo is a tricky beast as we’re not only accepting payments, we’re also paying people. Here’s how it works:

  1. Person A pays Carson Systems (Amigo) with their credit/debit card. We use Secure Trading’s XPay module to do this.
  2. Carson Systems generates an invoice (marked paid) and emails it to Person A
  3. The money goes into Carson Systems’ bank account
  4. Carson Systems uses the PayPal API to pay Person B

The last step is the really tricky one. Watch the video to see how we solved it!


RSS readers, view the video here.

UI design, check. XHTML, check. CSS, check.

David Stone | The Wireframe, The Development, Amigo | Saturday, May 13th, 2006

Jason finished the UI for Amigo late last week, so once I got to a natural break within the code I was currently doing I decided it was time to start on the XHTML/CSS (jumping in and out of code too often isn’t productive, wait for a nautral break!) - I’m sure Ryan, Gill, and Jason can’t wait to see something that both works and looks the part, I know I can’t!

While the XHTML/CSS isn’t completed quite yet, it’s been more interesting then other projects I’ve worked on: this has been the first project where I’ve built the wireframes in XHTML before any design has been done. So rather then coding the XHTML from a blank slate I’ve been refactoring (as such), and so far I’ve noticed a few things:

  • Early on we had something to look at. Yes it was rough, but it was in a browser - where it would end up, for everyone working on the project to see.
  • Refactoring XHTML is very quick - while some pages needed more editing then others they were all done quickly.
  • Refactoring CSS isn’t - removing redundant styles after the changes to the XHTML, checking all the browsers etc. isn’t as quick as refactoring XHTML!
  • Any interaction questions you had about the UI will become much clearer once a version of it is working with the back end of the application.

If your in a similar position any time soon, and haven’t tried "XHTML wireframing", I’d recommend it, even if just to see if it works for you and/or your team. Personally I’ve not 100% made my mind up, I’d like to try it again on another project before I do, but so far it seems mainly positive.

The servers are taking forever to get setup

Ryan Carson | The Development, The Servers, Amigo | Friday, May 12th, 2006

A screenshot of the Basecamp Milestones, showing the servers being late

We work with a company in San Francisco, who takes care of setting up, deploying and managing our servers. Amigo is going to be hosted on a single LAMP box at 365 Main (one of the world’s best data centers, in my opinion).

They were really responsive and wonderful when we worked with them on DropSend, but they’ve gotten really busy lately and it’s taking them forever to get our server deployed.

This has made it hard on Dave, our developer. He’s had to use his Linux box as a dev box. It’s not in a data center, so the connection is unreliable at best.

Lesson we learned: get your servers deployed at the beginning - don’t wait.

The Holding Page was Broken - Duh!

Ryan Carson | Video Diaries, The Development, Amigo | Wednesday, May 10th, 2006

In this video, we talk about how we screwed up the holding page. We were rushed to put it up and made a school boy error on the PHP. Goes to show that everyone makes mistakes!


RSS readers, view the video here.

HTML or Plain Text Emails?

Ryan Carson | The Development, Amigo | Tuesday, May 2nd, 2006

Dave (our developer) wanted to know if we were going to send out text e-mails when we welcome people to the service or html e-mails? We’ve decided to go with all plain text emails for now. It’s simpler and you know that everyone is going to be able to read them. Obviously text e-mails don’t look as nice as HTML, but it sure makes things simpler, as you don’t have to try to test the HTML e-mails on 50 different e-mail clients (ugh!).

URLs: pretty and readable

David Stone | The Development, Amigo | Tuesday, April 25th, 2006

… well, that was the plan, however so far we’d been down the route that users would use an email address and a password to login, I hear you asking how this affects URLs. Well, if we’re identifying users by an email address then it makes sense that their “rating page” could be accessed by a nice URL that looked similar to their email address. There’s the problem:

An email address, public, on the web = spam

Okay, so it wouldn’t quite be an email address, but for someone with the know-how it wouldn’t take much to get that information. Apart from not wanting to annoy the users of Amigo with more spam, given the nature of the service, spam is the last thing we’d want to be associated with!

Pretty URLs were the plan, so pretty URLs there will be, something had to change. The simple solution here was to have something else to identify users by, i.e. a username.

Designing the Architecture

David Stone | The Development, Amigo | Friday, April 14th, 2006

Dia UML Screenshot

I’m a strong believer that a poorly designed architecture will affect the application - it’s not a case of if, but when, and not in a positive way! Personally I find it so surprising that this phase of a project is ever overlooked, in a hair-pulling, teeth-grinding, shouting “NO” at the top of my voice kind of way! It’s frustrating.

When I’m involved in a project from this stage I always try to take a step back, do some analysis, think of objects, patterns and other UMLesk features. In these few days three books are always an arms length away, I highly recommend them all to anyone involved in development/software architecture.

I usually start on paper, and once I’ve done 50% or so I’ll move digital. I use Dia on Linux for my UML modeling, however there’s plenty of choice, and they’re all cross platform (apparently).

The UML will evolve over time, this should slow down as the product matures (assuming requirements don’t change) however, keeping the UML up-to-date is important.. at some point in the future it will be referenced by someone (myself or another) and if it’s not up-to-date I’d expect that hair-pulling, teeth-grinding, shouting “NO” at the top of my voice frustration all over again.

Powered by WordPress | Theme by Roy Tanck