Showing posts with label development. Show all posts
Showing posts with label development. Show all posts

Wednesday, November 7, 2012

Holy Grail? Really, CSS People?

I recently had a website to build where the desired layout was three columns - left sidebar, right sidebar, and center content. The sidebars needed to be fixed width and the center content area needed to be liquid and resize itself to use the remaining available space. Pretty standard stuff, right?
Now, CSS has a lot of good points, and I try to be a good girl and drink the Kool-Aid when it makes sense, so I sat down and started making divs. And failed. And failed And failed. CSS just would not produce the result I wanted. So, I said to myself, "Self, there are people out there better than you are with CSS. Surely one of them have solved this!" To Google I went! Where I discovered that the CSS crowd considers this layout to be a "holy grail".

I read dozens of complicated methods for achieving this. I gave some of them a try, but most simply didn't work, or only worked for certain content. That's not such a big deal. All tools have their strengths and weaknesses. What did make me facepalm is the lengths these people are willing to go in order to avoid using the tool that is sitting right in front of them and achieves this effortlessly.



I've got your holy grail right here. It's called a table.

<table style="width:100%">
    <tr>
        <td style="width:200px">Left Sidebar</td>
        <td>Center Content</td>
        <td style="width:200px">Right Sidebar</td>
    </tr>
</table>


There. Grail found.

Wednesday, October 10, 2012

Choosing a Webmaster

Everybody seems to have figured out that they really need to have a website for their business these days.

Excellent.

So they go out and throw thousands of dollars at the first person they don't understand. Because that means that person really knows what they're doing, right? RIGHT?

Not so excellent.

Then they figure out that they've made a mistake and are genuinely eager to correct it. To do that, they need another webmaster.  But they still have no idea how to choose one and they don't want to make the same mistake again. Plus they blew their budget on the first webmaster. So they decide that they're trapped and live with whatever mess they're original webmaster made.

Very not excellent.

If you choose a doctor, you know this person has, at a minimum, graduated from medical school and received a license. If you choose a lawyer, you know this person has, at a minimum, graduated from law school and passed the bar. Webmasters don't have any minimum requirements. Anyone can announce that they are one. So, how do you choose?

You Are Not Stupid

New clients often tell me how stupid they are because they don't know anything about how websites work. As if I could do their jobs!

There is no reason to expect that you should somehow simply have an understanding of website design. It's a skill like any other. The people who know how to do it sat down and learned it, just like you learned the skills necessary for your job. Your webmaster should be able and willing to explain what they are doing and why in terms you can understand. You are not required to blindly accept anything they say and sign anything they hand you. You don't need to understand all the technical details of how everything works, but they should be able to clearly explain what a domain name is and help you choose a good one. They should also be able to explain the benefit their choices have for you, not just for them.

When you ask questions of your webmaster, you should get answers, not technical obfuscations. Say you ask: Will I have to check another email address?

Bad Webmaster: Gobbledygook flux capacitor temporal shift tardis YOU MUST GIVE ME $500 MORE DOLLARS TO SAVE YOU FROM THE EMAILS gobbledygook blarg.

Good Webmaster: Not if you don't want to. I can set you up a professional email address, but forward the messages to your GMail account so you only have to look in one place.

Retain Control

Not owning your website address (domain name) is like not owning your business name. Do not sign on with a webmaster who does not give you complete control and ownership over your domain name and your hosting account. In the best case, even the most professional and qualified webmaster can get hit by a bus. In the worst case, your webmaster may turn out to be both incompetent and vindictive. If your webmaster wants to create a hostage situation, walk away. Period. Before committing to a webmaster and/or a hosting service, make sure of the following:
  1. Your domain is registered in your name, not the webmaster's.
  2. The email address for the domain admin contact is yours, not the webmaster's.
  3. You have the login and password to access a domain management area where you can change nameservers and/or transfer the domain. You don't need to know what to do with this information, but you must have it available if you want someone else to be able to help you.
  4. Your hosting account is in your name, uses your email address, and is on your credit card, not in the webmaster's name or on their reseller account. This is crucial if you ever need to get account information from the hosting company. I recommend not using a webmaster that hosts sites on their own server.
  5. You have the login and password to access your hosting account. You don't need to know what to do with this information, but you must have it available if you want someone else to be able to help you.
In general, websites follow the money and the primary email address. make sure that both are yours.

Your website should also be yours. Webmaster will often put a small credit for themselves on sites they build. This is okay, but you should be able to remove it if you wish. The webmaster should also not claim copyright for any content you've written yourself or any artwork created for you. If content or artwork has been licensed from elsewhere, you should have a copy of those licenses for reference if needed.

Get What You Pay For

Certain large companies have taken to sending salespeople out to small businesses to pressure the owners into paying hundreds of dollars per month for a poorly designed web page. They claim that they are doing huge amounts of search engine optimization (SEO) work and suchlike for this money.

This is ridiculous. They are doing no such thing. They are certainly not doing hundreds of dollars per month worth of work. A well-made website with good SEO work built into it will do just as well or better.

For most small businesses, shared hosting is fine, comes with all the tools you need, and costs about $10 per month or less.  If you are paying more than that per month, something is wrong.

In general, your webmaster should not be collecting monthly maintenance fees from you unless there are some very specific tasks they perform on your site every month. For example, if they update your calendar of events each month, then a reasonable monthly fee is fine. Otherwise, you shouldn't be billed unless you ask them to do something for you.

Competence Counts

Websites aren't just pretty. They need to work. It can be difficult to tell if a webmaster is technically competent from the outside, but there are some clues you can look for. Ask them for links to sites they've built.  When you look at them, don't concentrate so much on whether you like blue or not.  Look for signs that this person knows what they are doing.
  • Do things line up and appear to be the same size?
  • Are the fonts consistent,or do they change at random?
  • Are images scaled correctly, or do they look stretchy or distorted?
  • Are there typos?
  • Do links go to the right places, or are they broken?
Even people who don't know anything about websites know they want to show up on Google. Determining if your potential webmaster knows about good SEO is trickier, but there are some clues you can look for.


  • Check the page titles by hovering your mouse over the browser tab. They should all be different and contain reasonable search terms for the site.
  • If you have a browser that will show image properties, make sure that the images have alt tags that contain reasonable search keywords.
  •  Look for large blocks of text that are actually pictures of text. Search engines can't read these and a good webmaster will avoid them in favor of actual text unless the client insists on them for some reason.

You should also ask your webmaster if they speak any web development programming or scripting languages. You're looking for answers like: Javascript, PHP, Perl, Python, AJAX, ASP, etc. You don't need to know what these are, but it's tough to build a good website these days without getting into at least a little bit of coding, so your webmaster should have some experience in this area.

Providing Guidance

Ultimately, the decisions about your website will be yours, but a good webmaster will let you know if you are making a choice that will cost you in terms of usability or search engine rankings. As a test, tell your potential webmaster that you want the name of your business to be in very large text on every page and that you want it to blink. If they don't at least suggest that you rethink that decision, you need to talk to someone else.

There's more, of course, but it's hard to check for unless you already know what you're doing. Hopefully, this information will help you choose the right person to get your business online.

Monday, July 16, 2012

The Pareto Principle For Developers

For those who don't know, the Pareto Principle is that thing that says 80% of effects come from 20% of the causes. So, while ten goths may have collectively used all the eyeliner, two of them (we'll call them the Bogart Twins) used 80% of it between them. 

The Pareto Principle has been applied to software developers by saying that we spend 80% of our time on 20% of the work for any given project. I've come to the conclusion that this is hooey. We do not spend 80% of our time on 20% of the work. We spend 10% of our time doing the entire project and the remaining 90% is consumed by some minute detail that should have taken five minutes and ends up eating three days.

I once did a little project where I knocked out the code that did the actual work in a couple of hours. I then spent days battling the generic installer so I could deploy the thing. Which was frustrating, but not even close to the stupidest of the examples I can offer.

If you want to see me levitate with anger, let's talk about the time I couldn't get something to be the right color. It was a simple RGB setting. It was even called RGB. I checked my value over and over again. I tried multiple syntaxes. I pored over the documentation. I cursed the gods. Eventually, I stumbled upon the problem. Some clever soul had decided that RGB values should really be specified in alphabetical order, i.e. BGR.  They also decided that this was so obviously correct, it didn't need to be documented. I'm not making this up.

I've also spent absurd amounts of my time filling out structures. Filling out structures isn't a problem. Needs to be done. However, filling out structures where many of the members must be set and there is only one valid value for each one and it's cryptic and it doesn't default and you have to go look up what The Magic Value is for each one of them makes me want to take up drinking just to see if it all makes more sense with a bottle of Scotch in me.

I could go on. And on. And on and on and on and on and on. We all could. As I publish this, I'm actually a bit concerned that the planet will be knocked off its orbit by the sheer force of all the programmers nodding their heads.

So remember, when you pay a programmer for an hour of their time, remember: 90% of that is to pay a person to sit at a desk with their head in their hands weeping at someone else's remarkable stupidity.

Thursday, June 28, 2012

Reporting Bugs in Software

As a developer, bug reports are part of my life. I give a machine instructions. I send those instructions out into the world. Users type with their butts. I get bug reports on how that doesn't always work.

Or, my users do perfectly reasonable things and certain combinations of those things have effects that I didn't predict or handle. So, I get bug reports.

Some of those bug reports consist of somebody screaming at me about what an idiot I am and how upset the user is without providing any actual information. Some of them provide some information but few specifics and, again, a lot of screaming. Some of them clearly describe the problem. If you didn't already know, those last ones are the ones most likely to get fixed. Not because they didn't say mean things to me, but simply because they gave me what I needed to find and fix the problem.

There are certain members of my beta test group whose reports get my immediate attention. When these people report something, I know it's real and I know they've put an effort into providing me with the straightest possible path to the bug and the subsequent fix. If you want to be on a developer's priority list, consider following these guidelines for reporting bugs.

Things to include

 

Subject 

A brief description of the bug. The subject should allow the developer to quickly determine what area of the software is affected. This allows them to quickly assign the bug to the correct team member, and to group related bugs together. It also helps them to check out related issues and previously fixed bugs that might be affected by current work.
A useful subject line: Crash when loading invoice form
A not-so-useful subject line: CRASH!!!!

 

Version

As much information as you can provide about which version of the software in which you saw the bug. This information is often available in the About box for the software.
Example: Microsoft Word 2010 (14.0.6024.1000) SP1 MSO (14.0.6112.5000) (32 bit) as part of Microsoft Office Professional Plus 2010

 

Environment

Provide information about which version of which operating system you are using. Depending on the software about which you are reporting, you may also want to include information about your graphics card and driver, amount of RAM, etc.

 

Description

A complete description of the bug. This should include as much detail as you can give as to what you were doing when the problem occurred. If the software has modes, tell the developers which mode you were in. If the problem occurred when you saved, tell the developers whether you used a keystroke like Ctrl-S, or clicked on a toolbar button, or selected Save from a dropdown menu. The developer may be dealing with millions of lines of code. All the things that you take for granted because you always do it a particular way are critical in helping a developer track down which part of their code is causing the trouble.
A useful description: I was adding a new Invoice. I filled out the main Invoice information, then clicked in the Line Items table to add a new item. I filled out the Line Item fields and clicked back to the Invoice Date to make a change. My new Line Item disappeared.
A not-so-useful description: I tried to add a new line item and it disappeared.

 

Steps to Reproduce

Bug fixing gets a lot harder when you can't make it happen and you can't test whether it's gone. If you can give the developer exact steps they can follow to reproduce your problem, your issue will get fixed a lot faster.

Useful steps to reproduce:
Open any document
Click the Page Layout tab
Select all the text by pressing Ctrl-A
Click the Columns button on the ribbon
Click Three
Crash

Not-so-useful steps to reproduce:
Select some text
Set it to use three columns
Crash

Things to Not Include


As developers, we understand that bugs can be frustrating, upsetting, and even scary. We don't like them either. However, if you want to rant, you should talk to Customer Service. Development's job is to identify and fix the problem. Anything that doesn't help us do that is just a distraction. Along those lines, there are some things you want to leave out of bug reports.

 

Jokes

We appreciate that you want to soften the blow and humor is a wonderful thing, but a developer deep in bug reports and source code is in a very literal place. It may take them three readings to figure out that you are joking and, if your joke implies a problem, they may have spent an hour trying to track it down before they figure out that you're kidding.  Dry-as-dust technical information is the way to go.

 

Emotional Content, Emphasis, and Essays

We understand that the bug you are reporting may have caused you significant frustration, wasted time, and worry. We're really sorry about that. We didn't write it that way on purpose to upset you. We want to fix it so it doesn't upset you or anyone else ever again. Wading through three paragraphs typed in all capital letters about how stupid we are and how much of your time we wasted just makes it harder for us to dig the actual problem out of what you are saying. We get that you want to vent to somebody but, if you want your bug fixed, the developers might not be your best choice of outlet.

Most of the time, developers don't need to be convinced to fix a bug. We want to fix our bugs. When management or suchlike prevents us from fixing our bugs, we get very frustrated and gnaw on things. We are likely to understand why your bug is a problem simply by reading the description. We don't need an essay about why it's a problem if the program crashes when you try to put text in columns to understand why we should fix that. It's just more stuff we have to dig through to find the actual description of the bug.

 

Justifications

Either the bug happens, or it doesn't. The bug doesn't know or care that you have worked with fifteen other packages for the past thirty years and know all about software. Maybe you do, and maybe you don't. It doesn't change whether we can make the bug happen using the steps you provided. Again, we don't fix bugs based on the perceived credentials of the reporter. The only credential that moves somebody in my beta group up my attention list is that they have a history of being a reliable and thorough bug reporter.

In Summary

When reporting an issue to a developer, efficiency is everything. If it doesn't help them identify the bug, leave it out. If it does, put it in,