That's a good place to start.
Information Architecture is the tech you use to accomplish your site's goals. At Tucknologies we usually start right here...determining what types of architecture is needed to pull off the job. What server operating system? What type of CMS is to be used, or do we develop one? What database software are we going to use? There are dozens of questions that need to be answered. Picking the development language is usually the first step.
There are a lot of choices
Think of the computing environment as two ecosystems. One, is the Server and that exists at some point down the line from you, on someone else's machine. The second, is the Client side. That happens on your machine and right in front of your eyes. So when we talk about the languages to develop in, we're primarily concerned with the Server side. I say primarily, since the client side is limited in choices and almost all of the server side languages need the client side to work properly.
To pick one over the other usually is a decision based on the developer's experience in the particular language. Each has its own hiccups and idiosyncrasies. Some are better handling certain types of processes than others. We don't favor one or the other, we try to develop in a bunch of different languages. But for the purpose of this article, we'll provide insight on a few of them.
PHP or "Hypertext Preprocessor" is a free, open source software system. It requires the PHP license (easy to acquire) and writes a lot like C. In fact, most developers consider the syntax to be a lot like Perl. This MVC (model, view, controller) is quite robust and is used in a lot of programs. We have developed quite a few technologies with this language.
ASP is the Microsoft development language and is available free from Microsoft. It's a well known language that is free and supported by an industry giant, but it does require you to use .NET as well. The syntax varies, and it's hard to point to ASP and compare it to another language...since it varies so much. There is an API for it, that's through Microsoft.
ColdFusion is a great enterprise software suite. It's from Adobe, and we here @Tucknologies absolutely love the Adobe. (I think we all have some form of CS on our machines!) It's not free...and that's usually the hang up. It costs you $1,299 to buy...but the developer's edition is free. The license is through Adobe, which always gives you that extra piece of mind. It's XML based, so if you know that you'll be able to cruise in Cold Fusion. One of the pluses is that Cold Fusion integrates with the Adobe technologies like AIR. If your hosting provider offers Cold Fusion to you as an extra cost to your hosting fee...take it!
This Python is nothing to be scared of: The language is widely used and is open source. The license is a Python license, so you have to deal with the open source-y ness of the license but that's usually of little concern. The syntax has been explained to me as "C-Like" so if anyone has experience with C#, C etc they can probably pick it right up. Note that on shared hosting, Python scripts are usually run as CGI programs. Python is a general purpose scripting language often used to develop web applications. Python is arguably a more powerful object-oriented language than PHP, but the two languages are very similar making learning the other easy. Which is always a bonus!
Ruby (on Rails)
Nothing deploys faster than Ruby. It's one of the easiest languages to START something with, but the jury is out on how easy it is to finish. It's free, open source, and available online at http://www.ruby-lang.org/ . It's a newer language, and has some positives that make it a compelling choice (typically when time-strapped). It's often with the Rails network which is an MVC built on Ruby. All in all, a solid system.
Time to pick a host
So what kind of hosting you need? We prefer Liquid Web. As a partner, we are of course a little biased but their service is second-to-none. The products they offer are competitive, and the best part is all the real-time monitoring they do for your security. Heck, they'll even harden your PHP for you! We have used a number of different hosting services and have dealt with dozens more doing clients' websites. Liquid Web beat them all...in our opinion. Let me walk you through what we use to determine the host.
What is the size of the site?
The size of the site is a bit of a misnomer. Sure the site itself can be a "beast" in function, but what does the footprint look like? How many MBs & GBs does the site take up when it is ready to be deployed? The databases...are they pretty much full or will they fill up quite a bit over time?
You'll need to find out what the size of the site and system is to be on the server. That is a good place to start.
Media takes up a lot of space on a server, and can run your costs up if you aren't careful. For example, an image can range in size from a few KBs to over 1GB. We aren't talking about super big, fresh-out-of-the-camera images here, but images can take up a lot of space and cost you money with your host. Videos take a big chunk of space, that's why a lot of people prefer to host their videos on a Vimeo or YouTube. Then you can take the link and embed it without having to worry about the cost of storing and retrieving those large files.
Size of Expected Audience
Okay, smarty pants. We all know everyone wants the entire world to come to their website. We get it. That's not feasible in the real world. Ask YouTube how much their videos cost to serve each day to their millions of users! Research into similar websites is key, as is talking with your provider. If they will take the time to discuss your needs with you, chances are they'll be with you when you really need them to stop the Russian spammers from jamming your site full of comments. (Nyet!! Son of a Putin!)
Why does this all matter? Well the hosting companies are going to sell you service based on your storage and bandwidth needs. That is dependent on the size of your assets and system and the amount of push and pull you do. To get a better idea of what you'll need, you can do some research online. We've found a good resource from whoishostingthis.com which gives a pretty good baseline figure:
For example, a modestly-popular blog with 1000 visitors per day, a 100 kb page size, and 2 page views per average visitor will only need about 8.5 GB of bandwidth per month.
Your site might not ever exceed 1 GB of data transfer per month. High volume websites may exceed 1 GB of data transfer in a month, but the average business website can support up to 10,000 different people looking at their website and still not exceed 1GB of data transfer. (Source: anchor.com.au) However, if you are doing E-Commerce, social media or "rich" media like videos and animations it can go higher. The bigger the files you transfer to someone, the quicker that limit is reached.
Some hosts zing you pretty good when you go over your limit, that's why we would recommend a graduated hosting plan like they offer (again) at Liquid Web. They have plans that allow your site to grow and do so when you need it...without causing heart palpitations reading a bill! So look for solutions like their Storm Servers you can sleep well knowing that if that blog goes viral, you'll be able to serve the pages without being put in the poor house.
Operation System (OS)
Which operating system should you use on the server? That all depends. I have found that the two most reliable are the Windows Server software and Linux. There are compelling reasons to pick one or the other. It basically boils down to this: Are you developing on a Microsoft platform like ASP? Or, are you deploying a CMS with PHP at its core?
If you are working with Windows, stick with Windows. This will most likely cause the fewest headaches. The opposite is true with Linux...if you are "Off the 'Soft" then Linux is preferable simply because there are less things to go wrong. We have used either and both, and for most things we prefer Linux but there are some reasons that we'd use Windows.
Picking what you put your data in is a big deal. One would think that after all of this stuff we've covered, that this would be a simple calculation: Just go with MySql. Okay, that's the default and it works well but you need to determine what your database (DB) is going to do. Is the DB going to handle a lot of in-and-out data writing? Does it have the capacity to handle a large amount of data?
These are things you should answer!
Unfortunately, there are so many choices to pick from and so many reasons why you would want to pick one vs. the other, so we're providing you a link to see the comparisons yourself:
Generally, if you check the reviews that are available online that will give you a good starting point. You may want to look for programs that are designed for the purpose, say like an e-commerce based database. Do you need a relational database? A relational database is one that allows you to link several databases together and run "queries" on them to provide functions. Do you need a suite, or just a stand alone? Stand alone may just do the trick.
Lastly, compare the ease of use and take a look at the interface and screen shots so you know what you are getting into.
Managing this mess with a CMS
Picking the CMS (or creating one) is your next consideration. If it's a custom site, that doesn't mean it doesn't have a popular CMS. Okay, you probably won't be doing a custom site with a WordPress CMS (why?) but there are compelling reasons to use Joomla, Drupal or Magento (to name a few). For instance, the entire website can be build line-by-line to have custom functions and custom and still need a user interface for the client to post blogs and pictures. McDonald's uses Joomla for their websites, but they have a lot of custom functionality. Drupal is popular for this reason, as is Magento.
A CMS can be created specifically for the website, and in some cases that's exactly what is needed. So reviewing the pros/cons of the various CMSs out there will allow you to pick the very best one. Personally, I prefer Joomla because it allows me to create custom script within deployable modules. But hey, that's just me!
Now it's time to create the "look" of the website. Consulting your graphic designer or design book will go a long way. The same color and form theories that are prevalent in art school still apply on the web. You should know about your color wheel, the emotions it is supposed to elicit (some robust debate about this), the basics of form and function, composition, and light. Complimentary...contrasting...leading...bleeding...and a whole lot more. If you don't know how to design, simply pick up a good book on design. (Here is one example:
Your color palette should be one of the first things you think of. This book is a good guide for those who want to delve into color theory and make sense of it all:
The Style Sheet is basically the next step in your process. You have to know what types of colors, textures, effects and fonts you will use for the site. This keeps it all consistent, and having them put together into one document helps any creator or editor down-stream. The Style Sheet will come complete with both RGB and CMYK colors, the hexadecimal and/or Pantone numbers for the colors, and examples of the textures and other effects. (For example you could go for "brushed metal" and have a few examples of brushed metal that illustrate a range of effects to get the "look.")
Of course, nothing happens without the logo! The only reason it's not first is that most businesses and organizations already have their logo. True, they may want to spruce it up a bit but normally new logos come with new businesses...but moving on. The logo should be a document with at the minimum of two and the maximum of eight different ideas or iterations of the logo. These should be distinctly different. Care to discuss each one with the client is paramount, to make sure the graphic that represents the company is plain to see.
With the developer, the creative services team works on creating the CSS for the page. The CSS, or Cascading Style Sheet, is a way in which a website can render the similar look and layout across all pages, without having to insert the code for each look and layout on each page. This allows for complex designs and functions that all get their own distinct style. For example, you can have a CSS for a home page...then one for an internal page...and one for the contact form...one for the slider/carousel...one for the login form...
CSS is a combination of art and tech. This is why we cross-train our designers and developers in CSS. Because one will invariably need the other, just not always at the same time and not always working concurrently. At Tucknologies, we take CSS seriously! (If you want to be a good designer, you will too). All the actions, the animations and state changes have to be coded. One of the big advantages that CSS has is speed. It doesn't take long at all to render a site with CSS (normally). Another big advantage is the time it takes to change is a fraction of the time it would take to change every page!
Then of course, we turn to the User Experience. (Well that's in the top of mind as you go, but we have to mention it before we jump into coding!) This finds you working on creating galleries, sliders/carousels, forms, functions and really getting into the guts of how people use websites and what the site is supposed to accomplish. How will the menus work? Will there be a drop down, a fade, a cascade?
Maybe the client will want the users to have a profile. What goes in the profile? What functions does the user have to use, or are encouraged to use? Is there anything lacking for the user? Does the system, in current form, fulfill the user's expectations? All great questions to ask. Then there is social media. How much of a tie in do I want? You can pick between having them login with their ID, just the ability to share via their network of choice, or being able to post content through the social media network. Lots to decide on!
All of these things are considerations for you before you even START on coding the website. Next we will take a look at the Development portion of building a custom website. We hope you'll be back for that next week.