Category Archives: On Technology

What is a Technical Design (Or Why You Need a Blueprint)

30 Friday Mar 2012

Posted by in On Technology

≈ 1 Comment

Tags

, ,

Have you ever had a house built, or an addition added to your house? Did it go like this?

*****

“Good day, Mr. Architectman, I would like you to build a home for me,” Chris VonClient said.

“I would be happy to help, Chris. How big do you want the house to be?” Andy Architectman responded, tilting his head to the right so that he could hear Chris better.

“I was thinking we needed three bedrooms and two bathrooms. So I don’t know, two thousand square feet?” Chris was not really sure what he wanted, but he had a vague picture in his mind.

“Two thousand square feet, eh? Hmm. Yes. I can see it now. That’s enough for a big kitchen, vaulted ceilings, a den in the basement, a living room upstairs. Wait, you do want a basement, right?”

“Oh, that’s a great idea, Mr. Architectman. A basement is just what we need!” Chris was excited. He could see the house better already.

“Alright then. We can get started next week. How’s $150,000 sound and we’ll be done by September?” Andy was quite sure he knew exactly what Chris wanted.

“Perfect! Thanks Mr. Architectman!”

*****

I am hopeful that when you had your home built, it did not go this way. Somewhere in this process, Mr. Architectman built out a full blueprint for the project, perhaps even with visual aids like a 3D rendering of the home so you could walk through it.

Unfortunately, too many software projects are treated like the short story above. With a few descriptive words about the project, the developer is off and running and the client is left to wait for the project to be done.

Honestly, we have done projects this way at MINDSCAPE in the past. It was a long time ago, but still it happened. It was fairly standard practice in the software industry. There are two main ways to protect against this.

The first way is something called agile development. You can go ahead and look that up on Google if you would like, but basically it means that we work directly with the client through all phases of the project. The client asks for something small and we will deliver in a week or two. That thing is then evaluated, changed as necessary and we start work on thing two. It’s a great way to make sure the client gets what they want; but it has two downsides:

1) It is time intensive for the client. We’ll need your ear and your mind a lot of the time during development. That could be a month to a year of work, and not many clients have that time.

2) We don’t know how much it will cost because we are working collaboratively on it. That means we end up charging for all of the time we put into the project. Not many clients are willing to engage in that agreement.

So, we have taken the idea of agile development and married it to a more traditional process. Once we get to development, we make sure the client receives regular updates of what we are building and they will get to play with the software as we work. We do this by breaking up a large development into multiple milestones.

But to get to development, we first have to build the blueprint, and that’s where technical design comes in. There are three benefits to the technical design.

1) The client and the developer can look at words and pictures and sometimes even partially functional prototypes to make sure we see the same ideas.

2) The developer has a better understanding of what the client wants and how long it will take to build.

3) The client can take the technical design and have it quoted by other development companies. Sure, we’d like to have their business, but the technical design ends with a solid deliverable that will give other development shops a solid way to understand the project quickly.

So what does a technical design include? Much of it will depend upon the scope and complexity of the project, but it will always include one or more of the following:

Feature List

This is present in even the simplest design documents. It lists out the features that are needed with a description of what the feature does.

Wireframes

Often, we’ll pair the feature list with a visual representation of what each page may look like. This is not intended to be a final design, but rather a way to communicate how the feature will flow and look on the page. We often use a program called Balsamiq to help this process. Here is what a Balsamiq mockup looks like.

Prototypes

Sometimes, it is necessary to model interactions or complex use cases in a more dynamic way. In this instance we will build out a prototype. This allows the client to play with the proposed solution instead of just reading about it or seeing a picture. This is helpful when there is a lot of animation or fancy user interaction with the application. It is not the final solution, as it will not have any data or logic tied to it, but it is helpful for showing what the application should do.

No two technical designs are ever the same as we tailor it to the client, the project and the scope of work to be completed. However, the technical design should make the requirements clear to the developer and the client, should allow the developers to create a reasonable estimate of work and give the clients a deliverable that they can shop to other developers.

And it’s just a good idea to build a house with a blueprint and not an ambiguous conversation.

Scheduling Sucks (Or The Problem With Rampant Success)

09 Friday Mar 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Life as a Project Manager at MINDSCAPE used to be pretty nice. I know, because I was a project manager for a couple of years.

We had a solid team and plenty of work to keep us busy. What made it nice is that it was manageable. Between two designers and two or three programmers, it was not so bad keeping their schedules straight.

We had a nice process. The salesperson would enter a form with the information I needed to make the schedule. I would take the form and create a Basecamp project using the information provided.

The Basecamp project would hold all of the tasks we needed to complete and the communication that we had on the project. Basecamp still works pretty well for this, and we use it daily.

Once a week I would sit down, write out by hand the hours needed for the different projects that came in, and get to work on Google Calendar. Each person in the company had a calendar, and I would put an All Day event in place for what they should be working on each day.

In this way, I could model the 4 days it would take for design, the 2 days of design revisions we would need in a week, and then the HTML and other programming that a different resource would need to do when the design was complete.

It took a little while, but it was manageable. And it was free. Each person could check their calendar each day, and know the main projects they should be working on. Here is a look at a schedule from February of 2010:

Pretty crazy looking, right?

Well, those quaint days are long gone, and yet we have not updated our scheduling methodology. We tried sticking with this process, but now there are two project managers, an entirely new department for marketing and double the number of programmers. It has become onerous to keep track of what project has priority and what each person is working on.

Want to find when we can fit a project in or get a new project completed? Good luck tracking that date down. We just don’t have it right now.

The issue came to a head over the last few weeks. New projects started pouring in, as our two salespersons worked their magic and Mike, Pete and Paul got in on the sales too. It became very clear that we needed to find something new. It was time to evolve.

So what is that something new? We don’t know for sure yet, but I have really enjoyed LiquidPlanner so far. It certainly makes scheduling a breeze compared to what we have done in the past. I have spent the last three days adding nearly two dozen projects into the system, assigning them to resources and adding tasks and estimated effort to each. And every time I add a new project Liquid Planner updates the schedule for me.

I am pretty sure I cannot go back to Google Calendar.

I will circle back to this subject in month and let you know a bit more about how we have solved the scheduling problem.

(If we have not solved the problem by then, Sisyphus and I will be best friends.)

What Makes Front End Coding So Difficult (or HTML Black Magic)

24 Friday Feb 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Do you know what front-end programmers dream about? It is not an answer to the national debt, or if Democrats and Republicans can get along, or even if there is life on other planets. No, front-end programmers dream of something that seems entirely more difficult to attain.

A front-end programmer wants a world where they can do their work one time and be done.

It sounds simple, doesn’t it? Most of us go through life completing a task and knowing that having completed the task, there is nothing more to do.

Not so for the much maligned front-end programmer. Before I take you too deep into their dark, esoteric world of angled brackets, cascading styles and the abomination that is javascript, it will be helpful to know what a front-end programmer is.

I am sure there are many different definitions, but at MINDSCAPE, our front-end programmers take the pretty designs from a designer and turn it into the code that displays the website in a browser. It is not enough to take the design, turn it into an image and put that on the Internet. Once upon a time the world was that simple. But it’s not 1995 anymore, and our clients want to be found on the Web by their visitors. So, our front-end programmers must turn the design into hundreds of lines of code so that automated bots can crawl the site and index the content found there.

Our front-end programmers work their magic with HTML, CSS, javascript, flash and a number of frameworks and standards that help them do their work better.

It may not be simple, but it’s a fairly straightforward process. Or so it seems, until the first time they open up the webpage they just built in Internet Explorer. That is where things start to get messy.

You see, there are a lot of browsers out there. A browser is the program you use to see the Internet. Google Chrome, Firefox and Safari are a few of the modern browsers. They are considered modern because they support many of the features from the latest HTML standards (HTML 5) and CSS standards (CSS 3). The new standards allow our front-end programmers to do really cool stuff. And when not doing cool stuff, it helps them do the mundane tasks very quickly.

Well, Internet Explorer is a bit behind the curve, and that’s sort of an understatement. So our front-end programmers find themselves in a bind. Do they build the website to use the latest and greatest technology, or do they build the website to work in what is somehow still the most popular browser (see stats at StatCounter)? And if they choose to build the website for Internet Explorer (IE), do they optimize it for IE 6, IE 7, IE 8, or IE 9. You see, each version has its own interpretations of the standards. So what you build for one, is not going to work for the other.

Perhaps you begin to see why the ritual of making a site work in IE usually begins with animal sacrifices, pounding drums and incense. It’s another reason they make us work in the Pit.

Alright, so we don’t have to go quite that far. However, there are additional wrinkles to contend with. You see, we want to make our websites so that it is easy to extend them to work on mobile devices. Most new mobile devices, thankfully, use browsers that handle the latest CSS and HTML. That allows us to build a version of the site that works for both mobile and desktop with a minimum of additional effort beyond building the mobile site styles.

In the end, our front-end programmers must build the same site multiple times if we are going to make it compatible with all possible browsers. That means each site must be:

A site for modern desktop browsers such as Google Chrome, Firefox, and Safari. IE 9 handles most of what these other browsers do, so that is a step in the right direction. However, many of the features are supported in different ways by each browser, so we still have to define rules in multiple ways.

A site for IE 8 and IE 7. These browsers are pretty close together, and most of the time standard HTML and CSS will work well with them. Either way, it needs to be tweaked.

A site for IE 6. Microsoft has finally announced that they will be killing off this browser, and the front-end world rejoiced. It’s a nightmare to work with, and for the longest time it was the most used browser in the world. Check out the Internet Explorer 6 Countdown website. IE 6 usage is less than 1% in the US now! Yay!

A site for mobile. Even though the browsers are standards compliant, we still need to design and style the site differently for the mobile space. It seems easy enough, until you realize that there are dozens of potential screen sizes between mobile phones and tablets.

Now, there are ways that we combat this without having to build entirely new sites for the different browsers but it involves trade-offs. For example, IE 7 and 8 will not have rounded borders when we finish the site. To make rounded borders, we have to create many small images to create the corner. On modern browsers, it is a line of CSS to create a rounded border. That saves us time and allows us to concentrate on hundreds of other details that make your site successful.

In the end, sometimes it is important that we fully support older browsers. In that case, we can make it happen but it takes additional time and costs extra money. If you know you need older versions of Internet Explorer to work, be sure to consult with your Web developer before starting the project.

And if you do ask him to do it and you hear pounding drums, see strange flickering lights and smell smoke coming from his room, do not go in. You don’t want to know what it takes to make it happen.

Quoting a Project (or How Deep is that Rabbit Hole?)

07 Tuesday Feb 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Last year I had a few rooms in my house repainted. In order to determine which company I would use for the work, I invited them to the house to quote the work. I showed them the rooms, told them the type of paint and color I wanted, and told them when I wanted the work done by.

Each company was able to calculate the amount of paint they needed, the cost of the paint and how many people would need to work on the project in order to have it done by my deadline. Having painted a multitude of rooms before my request, they were able to imagine potential obstacles before they happened and be fairly sure that they were not missing anything in their quote.

The resulting quotes were very precise and given to me with a high degree of confidence.

Quoting a job for a new custom application is a lot like that, except that we can’t see the rooms ahead of time. In fact, we can’t see the rooms, because first we have to build them. The rooms that we see in our mind’s eye are often very different from what our client sees in their imagination.

Let’s ponder a request to build a rabbit hole. The rabbit hole needs to be 8 inches in diameter, be set in a yard full of lush, green grass, preferably under an apple tree and near a babbling brook. Beyond the tree should be a field of ripened, winter wheat; golden and dancing in the breeze.

Seems easy enough, except that getting the blossoms correct on the apple tree may take some doing. But, all in all, everything is out in the open.

That is, of course, until we build that rabbit hole and take a trip inside. Suddenly, there is a rabbit late for an important date; a grinning, invisible Cheshire cat; a hookah-smoking caterpillar, a mad hatter and an irate Queen of Hearts. And let’s not even get into the pills and potions that can change the user’s size and shape at will!

The client is completely nonplussed by our discovery. Of course the rabbit hole contained an entirely new world full of anthropomorphic creatures and nonsensical laws of physics! What other types of rabbit holes could there be?

Sounds a bit far fetched, doesn’t it? And yet, similar scenes happen in the software development world all of the time.

A problem is presented by a client in a short paragraph of needs and requirements.

A software engineer conjures up thoughts of similar software that have been built in the past as a basis for their quote.

A quote is given based on myriad undocumented assumptions and risks.

Three months later, the proud software engineer presents their creation to the client and is flummoxed as to why the client is so flabbergasted at the result!

It doesn’t have to be that way, and at MINDSCAPE, we do our best to eliminate as many doubts as we can before we begin coding.

The MINDSCAPE Process

1) Our sales team meets with a client to determine what needs to be built.

2) Our quoting committee meets to understand the client’s needs. If it’s a simple project for a client that we’ve worked with in the past, we may be comfortable enough to give a fixed price cost right then. Most times, however, we need more information before we can give a granular cost. Instead, we’ll give a large range of costs based on what we know of the project, but more importantly, based on what we think may be hiding down that rabbit hole. We’ve been down there a few times and know what sort of exotic features are lurking.

3) If the client finds that part of the range will fit their budget, we engage them for a one day, on-site (if possible) requirements gathering session. Two of our team members will sit down for an in-depth discussion about what the system needs to do, why it needs to do it and what benefits are expected.

The result of this meeting is a much better understanding of the system and leads to two courses of action.

A) If the project is manageable enough, we’ll have been able to document the vast majority of functionality and even have some rough outlines for what the different screens will need to do. This will give us enough confidence to bring back a fixed cost estimate for development.

B) If the project is very large, we’ll have a better understanding of the scope of the project, as well as potential risks. The next action is to engage in a Technical Design Document phase. Based on the on-site discussion, we’ll be able to give a better budget range and a cost for the Technical Design Document. If the more-defined scope is agreeable to the client, we’ll start on the Technical Design Document.

4) The Technical Design Document deserves its own post later on, but for now it’s enough to know that our engineers will grab their spelunking gear and head down into that rabbit hole. They will survey the landscape and draw out what it is they see. The client will give feedback during this phase to make sure that we are seeing the same thing in that rabbit hole that they are seeing.

5) Once the Technical Design Document is done, we present it to the client along with a final, fixed cost price for the development. The client can then work with us to complete the development or take our Technical Design Document to another firm for quoting. Either way, we’ve done the hard work to determine what’s down the rabbit hole; for our own sake, but also for our client’s sake and the sake of any developer that may work on the project in the future.

Even with all of this due diligence, it takes constant communication and interaction with the client to make sure the project is on course. The final scope of the project can change due to many issues (who can foresee a croquet game with flamingos as mallets and hedgehogs as balls?), but we do our best at MINDSCAPE to keep ahead of the game.

(And if you have not had the pleasure of reading Lewis Carroll’s Alice in Wonderland, you should at least browse the Wikipedia article so that this blog post doesn’t seem completely off the wall.)

Life in the Pit (or How to Pamper your Programmers

19 Thursday Jan 2012

Posted by in On Technology

≈ Leave a comment

Tags

,

The office of MINDSCAPE at Hanon McKendry is located in the heart of Downtown Grand Rapids. It’s on the sixth floor of an old building next to Van Andel Arena.

When the elevators open on the sixth floor, visitors are treated to an open floor plan, a nice reception area, a nifty coffee bar, some fancy table and chairs for informal gatherings and a half-dozen nice cubes where information workers are busily executing strategies for website success.

It’s a great place to walk into, and a great atmosphere to work in. The free soft drinks, breakfast foods and a hidden cupboard full of M&Ms and trail mix add to the lure for workers.

But there is a hidden danger, one that the programmers who used to inhabit the cubes near the reception area found out first hand.

You see, the lights are really bright and cast harsh glares on their dual monitors. Co-workers and clients bustle to-and-fro past the cubes, catching their eye and interrupting their code flow. Phones rang, impromptu meetings and parties broke out at the coffee bar and the student tours gawked at the programmers, making them feel like white collared monkeys in a zoo.

MINDSCAPE’s merger with Venux in 2010 precipitated a change. We needed more room for the programmers and the six cubes in the entrance area of the sixth floor were no longer enough.

The programmers moved down to an empty office space on the first floor, and it fits their needs much better. Take a gander at the advantages they enjoy, and see if you can figure out why it is called the Pit.

A look at the “Pit”

1. No Lights – it’s true, this is an advantage. Fluorescent lights are harsh and being able to see your surroundings clearly only entices distraction.

2. Silence – it really is golden. The phones are used rarely, the inhabitants speak softly and everyone understands they walk on hallowed ground. Creation is happening and it is given the respect it duly deserves.

3. Privacy – it is hard to say if no one visits because they do not want to interrupt, or because it has been forgotten what office they are in, or if it’s the four digit combination lock on the door. Either way, the programmers thrive knowing they can put their heads down and get work done.

Programming Nirvana

4. Windows – There is a lot of natural light during the summer thanks to a number of windows along edge of the office. True, it sometimes brings too much light, but being able to see outside is a pleasant reminder that there is a world beyond the 1’s and 0’s on their computer screen.

It’s nearly a programmer nirvana, although there are some drawbacks.

1. Bathroom Breaks – Here’s a recipe for disaster: put eight intense, focused programmers in an office with no bathroom on that floor and only one key to access the bathroom on the next floor up. They aren’t concerned with simple bodily needs like waste disposal, so when the need makes itself urgently known, mad dashes for the key are inevitable. Then imagine it happens at eight in the morning on an overcast day in the winter. Ahh, you see the issue. There is no light. And there happen to be a lot of chairs in the middle of the room by the conference table. And there is only one key.

2. Communication – Sometimes it’s almost like the Pit is in another country and not just a short elevator ride (or walk down the stairs) from the main office. We had some communication issues for a while, but we are learning to overcome that through repeated training sessions with both the Morlocks and the lofty denizens of the sixth floor, the Eloi. Walking through the door into the Pit is not akin to entering one of Dante’s circles. Riding the elevator up to the sixth floor and having it open to a bright, vibrant atmosphere full of smiling, intelligent, bubbly people is not at all like their nightmare of showing up to do a presentation naked. It will take continual effort, but the gap will be bridged.

(If you ask me, any blog post that manages a reference to two classics like the Time Machine and Dante’s Inferno is a success.)

Cloudflare – protect your website

30 Tuesday Aug 2011

Posted by in On Technology

≈ Leave a comment

Tags

, ,

A month ago, I wrote about the Google Page service.  The Page Service caches your static content and serves it up from their servers for faster page views.It sounds great in theory, and perhaps it will perform well in practice.  Currently, it’s still in a beta period and available to only a small set of webmasters.While I was researching that article, I stumbled upon a service called Cloudflare.  Cloudflare already does what the Google Page service does, but also protects your sites from known threats like spambots, can auto-minify your site’s CSS and Javascript files, hides your email address from any spambot that may get through, and a whole bunch of other cool sounding stuff.

Basically, they level the playing field for small websites. A small website no longer has to pay large sums of money to get the security and reach that giant, corporate websites get.  And somehow, Cloudflare manages to do it all for free.

I immediately put my wife’s site, www.branderphoto.com, onto the service.  It took only a few minutes to setup, and as long as you have access to your domain’s nameservers, it shouldn’t take longer than that.  Within an hour, Cloudflare was protecting our site.  It was cool to view the source on the page and see how their email protection hid email addresses.

Click for full image

I was very happy to see the threat panel. Over the last 30 days, Cloudflare intercepted 759 threat visits from 52 unique sources. I can view each threat from my dashboard.  I see their IP address, what kind of threat it is, how dangerous the threat was, the country the threat came from, and what happened to it.  Cloudflare maintains a list of IP addresses that are running bots and when a visitor from one of those IPs shows up, they are presented with a Captcha challenge. If the user can pass the captcha, they can gain access to the site. If it was a real person, the can leave a message as well.  This helps you make sure that real people are getting to the site.

As of right now, all of the threats were real and I have not had an issue with actual users being blocked.

As an owner of a website, it’s a no brainer to run my site through Cloudflare.

I wear another hat, though. I am also the Vice President of Technology at Mindscape.  Over the last few months, our bandwidth usage has gone through the roof.  We have taken a number of different measures to try and curtail the rising bandwidth costs, but nothing has really taken hold.

Not long after I started using Cloudflare for branderphoto.com, I decided to start sending our images and files from our webTRAIN platform through Cloudflare.  Each website on our platform serves its assets from one of four specific subdomains. So, I could essentially serve 90% of webTRAIN images by protecting those 4 subdomains with Cloudflare.

There were two things I needed to do.  First, I needed to upgrade to the pro plan. It’s $20 a month for the first website, $5 for each additional pro site in your account.  I needed it in order to serve a secure version of the files into the admin of our platform. I received the additional bonus of 15 minute increments on my stats, instead of 24 hours like the free sites have.

Secondly, I needed to do something about video.  Cloudflare protection and video served from the protected domain don’t mix well.  Embedding a YouTube video is fine, and so is serving your video from an unprotected subdomain.  So, while I tested the file serving idea on a small portion of our sites, our team got to work on making sure all video passed through a “video only” subdomain.

The small subset of files went great. We were saving a GB or two of bandwidth a day.

Well, on Sunday, I deployed our teams video solution and flipped the switch on our busiest file serving subdomain.  Check this out:

That’s one day of serving our files through Cloudflare across the busiest section of webTRAIN.  We had averaged about 60 GB a day in bandwidth on the four previous Mondays.  That single subdomain, serving files, was responsible for 25% of that bandwidth!

And check out the request numbers.  81% of the requests were served by Cloudflare and not by our server. That’s a HUGE number and big load off of our own machines!

We’ve been using Cloudflare for a month now, and have slowly put more reliance in it. Turning on our main fileserver to Cloudflare was a big step for us, and 24 hours in, it looks like the right solution for us.

Thanks Cloudflare!

Google Page Service

29 Friday Jul 2011

Posted by in On Technology

≈ 1 Comment

Tags

,

Do you feel the need, the need for speed? It’s an ongoing battle for coders and webmasters to make their page show up faster. A slow load time can cause the multi-tasking, instant-gratification-needing web generation to move on to another site before you have a chance to show them what your site is all about.

At Mindscape, we’ve made a number of optimizations to try and get our sites to load faster. We’ve re-indexed databases, compressed our many CSS files into a single file, enabled gzip compression on our server, and worked to improved our database queries. On the whole, it’s been very helpful.

Well, Google is coming to the rescue to make it even easier to have a fast page. According to this article, http://techcrunch.com/2011/07/​28/google-page-speed-service/, Google will soon be rolling out a service that will make your site load faster. The idea is that you point your DNS to Google’s server, and it fetches and caches your data to serve it up using a number of performance best practices.

Sounds like a nice theory, but there are a few questions.

1) What about dynamic content? Will it handle that well?
According to Matthew Prince, from Cloudflare (more on Cloudflare later), the method they are using won’t work well with dynamic content. He linked to a blog on his site, but I was unable to view the blog post. So, we’ll have to wait and see if Google handles this well.

2) Will Google use this to influence their search result? It’s been said that your load times can influence your search ranking. So if that’s the case, and you can pay Google to have faster load times, does that create a conflict of interests. I may be naive, but I like to think that Google has good intentions and would not push this as a way to directly influence their search rankings.

3) How well does it work? I decided to try it out for myself to see. You can test their service here:
http://code.google.com/speed/pss/index.html

Click to see the full image

First, I tested www.BranderPhoto.com, my wife’s photography business. It runs on webTRAIN, Mindscape’s powerful marketing and content management system. Brander Photo is using compressed CSS, so the load time for CSS files is low, but it has a lot of big images, which can be slow.

The test was run from the California server. It certainly looks as if it helps. However, it was interesting that on the repeat visit test, the original site was faster. That tells me that our CSS compression is helping, and after having the images locally, there wasn’t much time spent waiting on files. Good job webTRAIN! See the full test here: http://goo.gl/DBVEv

On the second test, I used our current Mindscape website. It is also on webTRAIN, but never received the compressed CSS update. So, there are a lot of CSS files that need to be downloaded the first time.

Click to see the full image

Google Page Service can speed up that content by about 50%. That’s a big increase!

The full test is here: http://goo.gl/tBjZ7

It certainly appears that Google Page Service can speed up your site. I’m interested in how it will work with a dynamic site, and not just a static page.

A competitor?
I saw a lot of comments from the Cloudflare team in the comments to the original article. I checked out their website (http://www.cloudflare.com/overview.html), and I was intrigued. It seems that you can get what Google is offering, and more, for free. I did not see a way to test their performance increase, so I’ve updated one of our less used sites to point to Cloudfare in an attempt to see if it can do what it says. It will take some time for the DNS to update, so watch for a follow up article in a week or two.

I’m most intrigued by something that has been plaguing us for a while, bandwidth lost to crawlers and bots. Cloudflare says: “We also block threats and limit abusive bots and crawlers from wasting your bandwidth and server resources.”

Now that’s something I can get excited about!

Conclusion
It appears that Google’s Page Service can help speed up your website. However, you may also want to check out Cloudflare in the meantime. It also looks like both services may have trouble with sites that are dynamic or that stream video, so you’ll want to do some research or try with a low volume site, before you dive in and make the change.

Google Apps Transition – The pain you’ll feel and how to fix (some of) it

14 Thursday Jul 2011

Posted by in On Technology

≈ Leave a comment

Tags

,

Google Apps for Business is a great solution for companies that want email, calendar and documents hosted in the cloud by Google.  Mindscape, where I work, has used Google Apps for Business for a number of years now. It allows me to have aaron [at] mindscapesolutions.com as my email address.  What it did not allow in the past was for me to access tools like Google Reader, Checkout, Picasa, and a number of other popular, ancillary services from Google.

What I could do, however, was create a second Google account using the same aaron [at] mindscapesolutions.com address. This account had to have a separate password, but as a standard Google Account, I had access to those other Google Services.

I wasn’t interested in using my work email to access those other services. So I made it even more complicated.  My wife runs her own photography business, http://www.branderphoto.com. I use aaron [at] branderphoto.com as my personal email. It’s also a Google Apps for Business account. So, when I wanted to access Google Reader, and Checkout and Analytics and Picasa, I had to have a separate aaron [at] branderphoto.com account, with a different password, to access those accounts.

The plus side of this arrangement is that I could have aaron [at] mindscapesolutions.com signed in and accessing email, and in another tab of my browser, have aaron [at] branderphoto.com signed in and accessing email.

The down side is that I would also have another tab open, with my other aaron [at] branderphoto.com account signed in, to access Google Reader.

All in all, it was as confusing as it sounds. So, it was with much rejoicing, mixed with some trepidation, that I transitioned my Branderphoto.com account to the new Google Apps for Business model last week (http://www.google.com/support/a/bin/answer.py?hl=en&answer=181867). With the new model, my branderphoto.com account will function just like a real google account and have access to all of the Google Services.  So I made the switch.

I had to create a new google account to hold my secondary branderphoto.com account data. Apparently it wouldn’t just merge them together.  The biggest pain here was exporting my Google Reader subscriptions and importing it to my upgraded branderphoto.com account.
Not super painful, but not as smooth as I would have liked it.

So, after reading a few blogs in my improved branderphoto.com account, I decided it was time to try clicking on a Google +1 button and see how that worked.  Epic Fail.

Apparently, my improved branderphoto.com account isn’t completely a real Google Account.  Services like Google Health (I don’t care), Google Power Meter (no matter to me), and Google Profiles (what!?) don’t work with Google Apps for Business users yet.

Soon after, I had a chance to try the new Google Plus service. Turns out I can’t use that with aaron [at] branderphoto.com.  And now that my secondary aaron [at] branderphoto.com is no more, I would have to use some other Google account to create my Google Plus account.  I have no desire to add yet another layer of complexity, so I guess I’ll be out of the Google Plus loop until my Google Apps account is fully functional.

Google Profile seems central to all that Google is trying to accomplish, so making my Apps for Business account behave like a regular Google account, but leaving out Profiles is like having an ice cream cone but leaving out the ice cream. Who wants that?

I got over the pain of not having a Google Plus account. It wasn’t that hard to do.  Today, however, more pain came.  My mindscapesolutions account was transitioned to the new model.  Since it also acts like a regular Google account, I can no longer have my branderphoto.com and my mindscapesolutions.com account signed in at the same time!  Ack!  Now I have to use Google Chrome, and Internet Explorer to have keep my business and pleasure separate.

It’s a pain, but one I can deal with. However, there’s one other way to handle it. You’ll need to enable sign in to multiple accounts.

See that cool, new Google bar at the top of your site? It looks like this:

Click on your email account to open up some options:

 

Click on the Account Settings tab:

Click to see the full image.

 

Click on Edit next to the Multiple sign-in and turn it on. Click Save:

Click to see the full image

 

Now, you’ll need to sign out of your account and sign back in. You should see a new “Switch Accounts” button in the options area.

Click on that to see all of the accounts that have can log into. The first time, you’ll just see one account. Click the sign into another account link and log in to the new account. You’ll then be able to switch back and forth between the two in the same browser!

Oh, and apparently Google already has some help documentation up for this. So if you don’t like my screenshots, check out Google’s video: http://www.google.com/support/accounts/bin/answer.py?answer=182343

Now, if they just get Google Profiles working….

The Need for Mobile Sites – a counter point

27 Wednesday Oct 2010

Posted by in On Technology

≈ Leave a comment

For users of mobile phones today, a website that offers a mobile counterpart is a website that will be returned to often.  For me, it’s ESPN’s mobile site. It has great navigation, easily allows me to find scores to the games I care about, let’s me watch games through a great Gamecast feature, and has all of the stories and analysis that I could want. On my previous phone, the T-Mobile G1, it was imperative to go to a mobile site. Full sites didn’t show up well on the small screen, and the the phones processor and browser technology were so outdated that it couldn’t handle anything with rich media.

Using that phone, it seemed that a mobile version of a site was a necessity.

18 months later, and a few weeks ago, I upgraded to the T-Mobile G2.  This phone runs on some pretty amazing hardware. I’m pretty sure my desktop computer in college wasn’t anywhere near as powerful as my phone is now.  It has a bigger screen and higher resolution than my previous phone.  It also will take advantage of the new HSPA+ network from T-Mobile (if it ever comes to Grand Rapids – it will be in 100 markets by the end of 2010).  That network allows phones to connect to the internet with speeds up to 14 mbps.  That’s twice as fast as my connection at home!

For now, I connect through the slower 3G or through a wireless network at home or in the office.  Using that speed, in conjunction with the great technology on my phone, I can now surf full websites without any issue. When I get to a site, it starts zoomed out so I can see the full page.  A simple double tap on any part of the screen will zoom in to that area. If it’s an article, the text resizes nicely and I can read it easily.

Now that the phone can handle flash and video, along with the browser making smart decisions like zooming and having a lot higher resolution, visiting a full website doesn’t bother me as much as I did. And if I’m soon zooming around the internet faster on my phone than I can on my computer, what need have I for a mobile website?

Certainly the navigation on a mobile site is almost always more handy for a touch screen that a full website’s navigation. And for now, there are a lot of phones and networks that can’t handle a full website well.  Mobile sites are the answer right now, and will remain that way for a few years.

But I’m starting to think that within 5 years, designing a mobile site will go the way of website design when designs for monitor resolutions of 640 x 480 were replaced with designs for resolutions of 1024 x 768.

Can you imagine what your phone will be able to do in 5 years?  The technology is changing so quickly, you might be tossing your laptop and your iPad aside to just use your phone.

Review of Rework by Jason Fried and David Heinemeier Hansson

19 Thursday Aug 2010

Posted by in On Books, On Technology

≈ 1 Comment

Tags

, ,

The founders of 37 signals have something to say about business, and it may not be what you are used to hearing.  This firm started out in 1999 with just three people. In 2004, they created Basecamp to help manage their projects. Soon, their clients wanted to use the tool themselves, so Basecamp was offered to the masses. It now generates millions of dollars a year in profits.

Between Campfire, Highrise, and Backpack, over 3 million people use their products.  While they were at it, they also invented an open-source programming framework called Ruby on Rails that powers many of the largest sites on the internet.

I’ve been keeping up with the teachings of 37 signals for years.  The talk about releasing code quickly, not out-doing your competition, and focusing on the basics. It’s a refreshing change from software and websites that try to do everything and be everything for every company.

This book is a compilation and revision of many of the business posts that they have released to the Web on their blog, Signal vs Noise.  The book is like the company’s products – no nonsense and easy to use.  They give you an idea or theme, expound on it for a paragraph or two, and let you decide how you want to use it from there.

I am going to touch on a few of the items that I found to be the most profound.  If you would rather skip that, I give this book a 5 out of 5 for anyone looking to start their own business, who has an idea about a business, or is working for someone else and wants to build the best product they can.

Planning is guessing

“Unless you are a fortune-teller, long-term business planning is a fantasy”.  When is the last time you successfully planned everything at a party, a luncheon or a vacation?  It’s hard to do well, and in a business, it is even more complex.  There are just too many factors to take into consideration.  Better to call your plans guesses.  They give you an idea of what you need to do, but you can then improvise and change direction when a better opportunity comes along.

They propose that you stop guessing at the future. Decide what is the most important thing this week, not this year.  Make it your priority today and get it done now, tomorrow will take care of itself.

Workaholism

“Not only is this workaholism unnecessary, it’s stupid.”  Pulling an all-nighter or working a lot of overtime demonstrates a capacity for pain tolerance, not a capacity for efficiency and innovation.  Sheer hours worked does not make up for a lack of innovation and organization.  Workaholics can create crises because they like to feel like heroes and they can make others that work in the company feel bad for putting in just their regular hours.

Your best workers are already at home because they figured out how to get it done faster.

Scratch your own itch

“The easiest, most straightforward way to create a great product or service it so make something you want to use.”  If you are your own customer, you know exactly what you want the product to do.  James Dyson built his own vacuum cleaner because the vacuumed he owned wasn’t very good.  Basecamp started as a home grown application for 37 signals that now services hundreds of thousands of users.

Draw a Line in the Sand

“Great businesses have a point of view, not just a product or a service.”  Determine what your product is about, and don’t change that for anyone.  Your strong stand will bring fans and haters.  That’s OK. If you try and please everyone, you’ll end up with a product that doesn’t do any one thing great.  It’s OK to say no if it makes your product stronger.

Embrace Constraints

“Constraints are advantages in disguise.”  When you have to make due with what you have, you end up getting creative.  Don’t have 3 months to create the feature, just 3 weeks?  Adjust your plan and build something useful in those 3 weeks.

Build half a product, not a half-assed product

“You just can’t do everything you want to do and do it well.”  Find the core of the product or service you are offering and make it shine. Leave the extraneous stuff for later, or better yet, for never.

Interruption is the enemy of production

“If you’re constantly staying late and working weekends, it’s not because there’s too much work to be done. It’s because you’re not getting enough done at work. And the reason is interruptions.” We have found this to be the case at my company, Mindscape.  We do our best to minimize active interruptions like phone calls, stopping by and instant messages.  Instead, we check out email at 11am and 4pm and leave tasks for people in Basecamp.  Of course, it doesn’t always work that way. I just had two emails, a person stop by my desk, and 3 instant messages pop up.  When that happens, it’s hard to remember what you were working on.

Quick Wins

“Momentum fuels motivation”. Break your long term projects into short term goals.  Releases and milestones show everyone that progress is being made. When people get stuck in a two year project, it’s hard to stay motivated through the entire lifecycle.

Don’t be a hero

“A lot of times it’s better to be a quitter than a hero.”  We’ve all come up against problems that we thought would only take a couple of hours, but ended up taking a couple of days.  Buckling down and finding the solution is great, but sometimes the better solution is to find a different tact.  There were a lot of other items you could have accomplished while you were working to overcome that hurdle.

This doesn’t mean quit at the first sign of a struggle. Instead, set yourself a deadline for the task. If you haven’t finished and you think you should have, bring in a fresh pair of eyes. Sometimes they can point out something obvious that you were too deep into the problem to see.

Say no by default

“Start getting into the habit of saying no-even to many of your best ideas. “  Henry Ford once said, “If I’d listened to customers, I’d have given them a faster horse.”   Keep things simple, remain true to the product that you want to build, and make stand for what is right.  This is one of my favorite chapters, and something I’ve been preaching for years.  Sometimes you have to protect the customer from their decisions, even if they don’t know why.  But keep your mind open. If you say no to the same thing every day, then you probably found the next feature to use.

Let your customers outgrow you.

“There are always more people who are not using your product than people who are. Make sure it is easy for these people to get on board.”

Each chapter is full of useful information and fresh ways at looking at business. I don’t want to give you a free pass to everything that the authors preach, so I’ll just pick out a few more chapter titles that I thought were interesting and that should wrap up this review nicely.

  • Emulate drug dealers. – Make your product so good and so addictive that a small free taste makes them come back with money.
  • Send people home at 5 – Busy people get the most done. Let them go be busy.
  • ASAP is poison – Stop saying it. When you add ASAP to everything, then everything is high priority. If that’s the case, then there no longer is priority.
  • Inspiration is perishable – Ideas last, but the inspiration to act on them does not stick around.

Rating: 5 out of 5 – I’ll be reading this book often  Check it out yourself by clicking this link.