Ecofont for graphic designers — use less ink, help the environment

July 2nd, 2009 by John Reeve

Ecofont from SPRANQ creativeFor those print designers out there looking to lessen their impact on the earth with more than just recycled papers and soy-based inks, have a look at the Ecofont. The folks over at SPRANQ creative brainstormed several ways to deconstruct letter forms to decrease ink usage while maintaining readability. The end solution was rather simple, put a bunch of holes in it. Similar to how outdoor recreational companies have lightened the weightload of metal gear by drilling holes in them, Ecofont removes several small circles from each letter. The result is a typeface that uses up to 20% less ink.

In addition to using this new font, SPRANQ offers some other ideas for increasing environmental awareness:

  • End-users: print only when necessary, use a modern, efficient printer and use unbleached paper.
  • Graphic designers: use modern colour separation techniques to avoid unnecessary wastage in ink. In paper choice, take the environment into account.
  • (Offset) printers: avoid modern laser techniques that make ink indivisible from the paper. Keep an eye on innovations, such as plant-based ink.
  • Printer manufacturers: invest in environment-conscious innovation.

The Ecofont is based on Vera Sans and is available for Windows, Mac OSX and Linux. It’s free to download and free to use.

Tags: ,
| No Comments »

Tags: ,
Bookmark:
  • Post to Del.icio.us
  • Post to Digg
  • Post to Google
  • Post to Ma.gnolia
  • Post to MyWeb
  • Post to Newsvine
  • Post to Reddit
  • Post to Simpy
  • Post to Slashdot
  • Post to StumbleUpon
  • Post to Technorati

Simple is a Relative Word

June 30th, 2009 by John Reeve

It seems that the holy grail of any web-based project management software app is a state of consumer nirvana collectively coined as “simple.” The word has become so popular — and mis-applied — that compound superlatives are becoming more commonplace; “absurdly simple”, “unbelievably simple”, and so on. Yet, it is difficult to objectively define simplicity because it is entirely based on the perspective of the small business using the software. Before you adapt any web-based project management software into your small business, cut through the hype by considering which of the perspectives below might define your needs best.

From nothing to something: Getting your business online the first time

New small businesses spring up every day. Others have been running for years using Excel spreadsheets for their project management needs (not to mention, time tracking and task management). Both of these businesses have one thing in common. They need very little to get by at first. Although many of the “silo” apps out there will work in this scenario, there is always the likely possibility that you will outgrow these applications. If you find yourself using a hosted project management app for the first time, there are a few factors to consider.

  • What exactly do you need from an online app?
    Time tracking, task management, document sharing, invoicing, expense tracking — these are all features to consider.
  • How much do you expect to grow in the next year?
    …and will the application grow with you? Will it be around in a year?
  • What is your budget?
    Can you afford to use several applications as your needs grow or does it make better sense to start out with a more comprehensively featured app that you can grow into?
  • How portable is your data from one app to another?
    If you decide to move on, can you get your data? It is, afterall, your data.

Scaling down: Ditching bloatware for fresh alternatives

Many of us, including Pelago at one time, have been saddled with MS Project for numerous reasons; it was free, the PM knows it best, corporate really likes those Gantt charts, etc. The truth is that MS Project, along with many other Enterprise level applications, are overkill for most small businesses. Many of them have been around for years and have recently entered the online marketplace with web-based versions of their project management software. Don’t assume you need to migrate from one to the other. It is in your best interest to research web-based alternatives that don’t have a traditional desktop-based business behind them. Perhaps you are a small design firm using the industry standard software and find its web-based counterpart to be lacking, or you just need a cheaper option. These hosted alternatives are usually built by smaller companies with fresh ideas and very little vulture-ish corporate overhead and are targeted toward the lightweight needs of a small business.

The even trade: Moving from one medium another

The move to online productivity tools, and project management software in particular, is becoming more commonplace among small business. Many security concerns are being addressed and the idea of storing sensitive data on remote servers is becoming more practical. The company culture of modern-day small businesses is becoming one that is becoming increasingly more comfortable with using software over the web. And so it makes sense that many small businesses are looking to ditch their desktop apps in favor of online options. In addition to the benefits of using a centralized web-based app that can be accessed from anywhere on the planet, you have an effortless and responsive productivity tool without the IT and licensing worries that plague desktop software.

Tags: , ,
| 1 Comment »

Tags: , ,
Bookmark:
  • Post to Del.icio.us
  • Post to Digg
  • Post to Google
  • Post to Ma.gnolia
  • Post to MyWeb
  • Post to Newsvine
  • Post to Reddit
  • Post to Simpy
  • Post to Slashdot
  • Post to StumbleUpon
  • Post to Technorati

Web design business mistakes: Using the right web-based tools

June 23rd, 2009 by John Reeve

Part 5 in a 5 part series

Get online with easy-to-use, comprehensive project management software—and use it!

Whether it’s off-the-shelf project management software, an affordable hosted solution such as our software, Intervals, or your own internal system, every web design and development company (including freelancers) benefits greatly from good project management software. Not only does it help avoid going over budget on a particular project by giving you a running count of time and resources spent, it also helps you better budget for future projects by summarizing how time was spent on past projects. It also reduces paperwork, facilitates collaboration through group task management and document sharing, and makes billing easier. Make it a requirement, not just a suggestion, that your employees or freelancers use the system as part of their work process.

When shopping around for the best project management, time tracking and task management software, we recommend you look for the following:

  • Strong time tracking tools with useful reporting
  • Intuitive task creation, assignment and management
  • Unlimited user accounts—don’t pay higher fees for having a larger team
  • Analytical/productivity tools and reports that let you run the numbers on your project from a variety of angles
  • Financial tools in the form of financial reports and invoicing features.
  • An elegant and easy-to-use user interface—you’re a design firm; your project management software should reflect that
  • Client access—the ability to allow clients to view or access part or all of the system so they can track your process and progress. While it may be a bit unnerving at times to allow clients “in,” if you value accountability all your potential client arguments will be instantly supported by your numbers.

How Pelago learned this the hard way

We started work on a large contract that required hiring several subcontractors. We hammered away at the project for weeks, not tracking a single minute of it. When our subcontractors invoiced us at the first milestone we were shocked. It was twice the amount we had budgeted. Our profits from the project were reduced to nothing. Tracking our time would have alerted us to the project going over budget. Not all was lost. From this fiasco was born our search for a viable project, task and time tracking solution. We tried paper timesheets, Excel spreadsheets, open source projects, and a few online project management apps, before rolling our own web-based software. Intervals proved to be invaluable for tracking our time on any project, large or small, by accounting for all of our billable time and alerting us to overages before they happened. Now that we are more disciplined at time tracking and task management at Pelago, we have experienced far fewer mistakes and increased our billable hours and proficiency. If small businesses can learn from our mistakes, why not also learn from our solutions?

Tags: , ,
| 5 Comments »

Tags: , ,
Bookmark:
  • Post to Del.icio.us
  • Post to Digg
  • Post to Google
  • Post to Ma.gnolia
  • Post to MyWeb
  • Post to Newsvine
  • Post to Reddit
  • Post to Simpy
  • Post to Slashdot
  • Post to StumbleUpon
  • Post to Technorati

API Authentication Methodologies

June 19th, 2009 by John Reeve

Building an API?

In the midst of building an API for Intervals, our web-based project management software, we researched several options for authentication. In case you are considering building your own API, we’ve published an overview of each method below.

  1. HTTP Basic Authentication.
    Similar implementations: Basecamp (http://developer.37signals.com/basecamp/), blogger (deprecated) (http://code.blogger.com/archives/atom-docs.html#authentication)
    Requests are authenticated in the form of the user’s username and password. Very easy to implement. Low security, but can be reinforced through the use of SSL/TLS (available on top three plan tiers). Users can disable API access from third-party apps at any time by changing their username or password.
  2. HTTP Token Authentication
    Similar implementations: Freshbooks (http://developers.freshbooks.com/), Highrise (http://developer.37signals.com/highrise/)
    Requests are authenticated through a token. Each user possesses a unique token, retrievable on that user’s settings page. Rather than entering username/password information, users just key in their token. Also very easy to implement. Low security, but requires a more active role from the user. Security can also be reinforced through SSL/TLS (available on top three plan tiers). The token is a hash of the username and password, meaning users can enable or disable API access from third-party apps at any time by changing either. With this implementation and the ones following, users never have to hand over login credentials to third-party applications.
  3. Three-Legged Authentication
    Similar implementations: Facebook Connect (http://wiki.developers.facebook.com/index.php/Authenticating_Users_with_Facebook_Connect), Yahoo! BBAuth (http://developer.yahoo.com/auth/), Google AuthSub (http://code.google.com/apis/gdata/auth.html#AuthSub)
    In this approach, each developer registers for an API key. Requests are authenticated through the developer’s API key and a user token. A token is retrieved when the API application redirects the user to a secure Intervals login page. After the user grants access to the API application, the API application retrieves the token. High security, but harder to implement. Also, a browser is required to grant authorization (though just once). May be overkill for developers building in-house applications. Users can disable API access per application by revoking access.
  4. Three-Legged Authentication with Request Signing
    Similar implementations: flickr (http://www.flickr.com/services/api/auth.spec.html), OAuth (http://oauth.net/core/1.0/#anchor9), Twitter (uses OAuth: http://apiwiki.twitter.com/OAuth-FAQ), Google OAuth (uses OAuth: http://code.google.com/apis/gdata/auth.html#OAuth), Yahoo! BBAuth
    Identical to #3, except API developers select a secret password when they register for an API key, and use this password to sign all requests. If any requests are intercepted, no modified requests can be made unless signed by the password known only to the developer and Intervals. Very high security (though not impenetrable), but more difficult to implement. May be overkill for developers building in-house apps. Options 3 and 4 can be implemented simultaneously with the decision to sign requests left up to each API application developer.
Tags: ,
| 7 Comments »

Tags: ,
Bookmark:
  • Post to Del.icio.us
  • Post to Digg
  • Post to Google
  • Post to Ma.gnolia
  • Post to MyWeb
  • Post to Newsvine
  • Post to Reddit
  • Post to Simpy
  • Post to Slashdot
  • Post to StumbleUpon
  • Post to Technorati

Web design business mistakes: Setting client expectations

June 16th, 2009 by John Reeve

Part 4 in a 5 part series

Know when to say no—set client expectations

We all want to make our clients happy, build a good reputation, and land more work, but occasionally the best way to manage a project that is running amok is to know when to cut it off. When a client has expectations that are beyond the ordinary or the reasonable, you can accommodate to a point, but ultimately you will need to draw the line. The sooner you make that clear to a client, the less likely it is that your project will become bogged down with extra deliverables and go over time and budget. Some ways to avoid this:

  • Build a cushion into your timeline and budget. A reasonable margin of error is typically between 10% to 15% of the total budget. This will allow you to give the client some freedom for last-minute changes or additions within their expectations. At Pelago, we only sign Time and Materials contracts, but it doesn’t hurt to point out that work requiring the cushion is in addition to the original estimate. Keep the client apprised they are starting to add to the budget and you will avoid handing them an unexpected invoice at the end of the project.
  • If the client has additional requirements that will change the scope of the work, but does not have the additional funds, suggest re-prioritizing the project features. For example, “We can implement X, but since it entails a great deal more work than covered under the original estimate and your budget, we need to take feature Y off the list.” It is also important to track these items separately from the original deliverables. This way, you group the work you did within the original estimate of work separately from additional work —extremely valuable not only to you but to the client as well. When the client is wondering why the project went over budget, it’s easy to justify, especially if you are tracking your time on the project.
  • Working with a client sometimes means fielding work requests from multiple people inside the organization. If possible, require that all of the client requests and communication to be handled through one point person. This will save you a lot of headache and help avoid doing the same work twice. By tying work requests back to specific individuals you create an environment of accountability. Clients will be more likely to get their act together and get more organized after seeing an invoice that reflects the effect of their multiplicity on the bottom line.
  • In our experience, flat bidding on custom web-based software projects is nearly impossible. The client usually only has a minimal understanding or vision for what they are trying to create. And in most cases, they don’t understand the web as a medium enough to realize how much of an undertaking these projects can be. Once they see the project starting to take shape and their vision become tangible the requirements start to change. We’ve embraced this as a natural part of the web development process and handle it with Time and Materials contracts. They are far better for you and the client, enabling both sides a way out and a way to surpass unforeseen or miscommunicated expectations.

You can be accommodating to clients while still running your business at a profit, as long as you set clear expectations from the beginning, let clients know when they are adding to those expectations, and renegotiate expectations (and price tags) to ensure that everyone will be happy with the final product.

How Pelago learned this the hard way

Several years ago, when Pelago was just getting its start, we signed a big client with a big name. We were starry-eyed and said ‘yes’ to everything they put in front of us. And we delivered the work immediately. We had set a precedent with this client, telling them, without words, that they would get what they wanted. When we were informed that our final invoice wouldn’t be paid because the client didn’t deem the work ‘billable,’ we were crushed. Being the ‘little guy,’ we had no options really to recoup the money. If we had practiced saying ‘no’ there would have been an established protocol and we may have avoided this scenario.

Tags: , ,
| 5 Comments »

Tags: , ,
Bookmark:
  • Post to Del.icio.us
  • Post to Digg
  • Post to Google
  • Post to Ma.gnolia
  • Post to MyWeb
  • Post to Newsvine
  • Post to Reddit
  • Post to Simpy
  • Post to Slashdot
  • Post to StumbleUpon
  • Post to Technorati

Contact / Newsletter Information