Let me introduce Ani Manjikian to you today. Author of Spirit of the Lone Horse, Ani currently works as a freelance web designer and is here to educate us on the basics of what to do to get your website up and running. I am so thankful that I met her and that she agreed to write this post because I am totally ignorant about web design. I think you will find her advice both readable and applicable. I know that even in my ignorance, I could understand and follow her take on web design. Thank you, Ani for coming and giving us all a little more insight into the webby world.
A Beginner’s Guide to Websites
(What you need to know before you build your website)
Authors hear it all the time. They need a website or some place where people can find them that’s a little more permanent than Twitter. How and where a website is built is just as important the content it contains. Most websites have less than two seconds to make a good first impression before a person moves on. Authors need ones that visually represents their books and keeps readers interested, so they stick around and learn about all they need to know about the author and their writings.
Create and protect a brand
A first impulse might be to create a Facebook page or WordPress.com blog. Those are great options for a temporary home to start building buzz for a book that might not be ready yet or just coming out. After that, those should only be used as a supplement to the main website.
The website needs to do for the author what a cover does for a book, reflect the who, why, where, and how of the content. People recognize brands by their layout, color scheme, and logo, first, and the text that they use second, so each author needs something that is unique to them. With Facebook, a brand can get lost in their color scheme because of the limited options that are available for changing things around. WordPress.com allows for CSS customization, for a yearly fee. It doesn’t allow the author to completely change the layout by modifying the template files, but it does provide the capability of changing the color scheme, font, and background so that the site will be more unique than a standard template.
The best thing an author can do is to self-host a website. Self-hosting doesn’t mean buying a web server and trying to connect it to the Internet. Rather, it’s buying a hosting package and domain name, choosing a web application, and hiring a developer.
Finding a host
Don’t do a random search for web hosts. Their web pages are designed to make them look like the best possible solution in hopes of a sale. Some of the ranking sites are just fronts for web hosts affiliates. The best place to find and research hosts is the Web Hosting Talk Forum (http://www.webhostingtalk.com/forumdisplay.php?f=1). The site has been around since 2000 and is a hangout for both web hosts and consumers.
After narrowing down the web host choices, do some research. In Google include the words review, customer service, or scam after the name of the provider to see what comes up. Find websites hosted by the provider and then check their domains through Simple IP (http://sameip.net/) to see how many sites are hosted on the server. Hosts that take big servers and cram as many sites on them as possible should be avoided or at least have their next level plan looked at. The more sites on a server, the less resources allocated to each site, which in turn affects how fast the page loads. Page load speed plays into the calculations that Google and other search engines use to order their results. Finally, beware of the term Unlimited. Servers have only a finite capacity. Call the provider up and ask them to define the exact amount of storage, memory, and bandwidth the selected plan has. This will provide the details of the hosting package and a taste of the customer service they provide.
Words like shared, cloud, virtual private server, semi-dedicated, and dedicated will come up when looking at hosting plans. Each type of hosting has their own pros, cons, costs, and benefits. Shared is the most basic option. It’s a bunch of sites on one server. If something goes wrong with one account, it could affect others and, worse, if there is a problem with the server, all the sites are impacted. VPS and cloud are the same thing, just explained two different ways. They are a group of servers networked together so they appear to be one server. Resources are shared amongst each account, but there is redundancy built into the system so that if one part fails, another part can take over. Semi-dedicated is a slice of a server while dedicated is a whole one. Don’t worry about these last two unless a server manager is in the budget because they require management beyond what is provided in the control panel of most shared and VPS hosting accounts. Shared is the cheapest, and probably the best for someone starting out, but go with a VPS, if it’s in the monthly budget, due the redundancy and ability to grow as the site grows.
I’ve been using Las Vegas Web Hosting (http://www.lasvegaswebhosting.com) since 2003. The president of the company, a friend of mine, inspired one of the characters in my books and their love of knowledge.
Registering a domain name
Some hosts offer a domain name as part of their hosting package. Say thanks, but no thanks to that and register a domain name with a separate registrar. That way, if something happens to the host, the domain name is safe and can be moved to someplace else. For a registrar, I recommend NameCheap.com or BulkRegister.com, both resellers of ENom. I’m saying this from experience, not because I’m any sort of paid affiliate. I’ve dealt with several others and not been happy with their price, customer service, or tactics to keep the domain name under their control.
As far as choosing a domain goes, use something that contains a keyword to the book or series being promoted. The book or series title is preferable since Google and other search engines look at urls as part of their ranking calculations.
Once the domain name is registered, the contact information for it must be kept current, especially the email. It’s easy to forget, but it’s the most important thing that can’t be. Registrars have only the contact information to verify the identity of the registrant, admin, and technical person associated with a domain. They expect that any changes to the domain name will be made through their interface. If a login is forgotten, they will use the email address on file. If that email is incorrect, then they will need documentation to give back control of the domain name.
Selecting a platform
Websites come in three flavors: static sites, something custom built, or a standard Content Management System (CMS) or blog built around specific needs and goals. Unless the site only consists of five pages or less that doesn’t need to change that often, I wouldn’t recommend going with the static method. Custom built is nice if the needed functionality has never been done before. However, I would strongly advise against going that route, just in case one developer needs to be fired and another one hired. Instead use a pre-built package and customize it. That way, if switching developers is required, the new one only has to be paid for learning the additions or changes to the standard platform instead of learning the complete infrastructure and programming of a custom built one.
I’d go with WordPress for a simple site that doesn’t have many users or feature requirements. For something that can handle multiple users with finite security control and different content types (think forms to fill out when posting stuff), go with a more traditional CMS like Drupal. Joomla’s decent, but it’s not as intuitive as it should be.
Choosing a developer
There are a lot of developers out there, so the process of finding one can be intimidating. The first thing is to consider how much they are willing to do the site for. It goes without saying that the more complex the design and functionality, the higher the price. Be wary of the designers who want to do even simple sites for nearly no cost, though. They are either selling a modified template they’ve used for different projects, might lose interest in the project when a higher paying one comes along, or are doing so many they only spend enough time to develop the site before shoving it out the door and moving on the next.
The best developer is one that will not only take the time to understand the needs of the site, but take the time to build a relationship with their client. They will also test a site on multiple browsers and devices once it’s complete. Different browsers use different interpreters to render the same code. Also, now that mobile devices are becoming the primary way of viewing websites, a site has to function and look good on a variety of screen sizes. If a developer doesn’t know or care about mobile design, don’t use them.
Look at the developer’s portfolio. If they don’t have one, don’t use them. If they do, but the designs all look like variations of each other, question what they did and why they did it. If their answers are unsatisfactory, walk away. Ask for references. If they don’t provide them, walk away. While working through the process of coming up with design and structure for a site, don’t assume anything. Put everything desired down and discuss it with the developer. Be open to what they have to say. If they seem hesitant or a little wary of certain requests, press for more details. The more exotic and non-standard something is, the more it will cost because of the time and effort involved.
Once the developer comes back with a plan, review it carefully to make sure it meets all discussed needs and requirements. After the ink dries on the contract, sit back and let the development process happen. A good developer doesn’t want to be micromanaged nor have to adapt existing code to random changes because of impulsive thoughts, trends, or fads. They might agree to do minor changes based on functionality tests or browser compatibility reasons, but anything else is called “scope creep.” Developers hate the creep because it makes them feel like a project might never end. Most good developers, in fact, will have a clause in their contract that will list exactly what they are going to do and anything outside that scope has to go through a change order or addendum process. In fact, if a developer doesn’t offer to sign a contract, don’t use them. A contract is meant to protect both parties. Anything else can boil down to a “he said, she said” argument even if emails are involved.
Backup, backup, backup!
One last piece of advice, make sure to keep a current backup of the website and the files used to create it. This includes any original layout and design assets created by Photoshop, InDesign, Illustrator, and other programs that use objects and layers. That way if a change in the design, site, host, or developer is needed, it can be made.
Find Ani’s ebook on Amazon: Spirit of the Lone Horse. Thank you for stopping by. Ani and I appreciate your likes, shares, and comments. ❤
goodreads.com/lonehorseend – my GoodReads author profile
https://www.amazon.com/author/ahmanjikian – Amazon author profile
https://www.facebook.com/StarsofHeros – FB Series Page
http://unsolicitedpress.com – Publisher
http://www.amazon.com/Spirit-Lone-Horse-Stars-Heros/dp/0692364722 – Paperback version of the book
https://twitter.com/lonehorseend – Twitter