In the early days of mobile development, I remember developing apps for flip phones. When I worked for DTN we wrote a mobile app, which we called WAP (Wireless Application Protocol), that did stock quotes, weather updates, and news feeds. This was way before smart phones became popular, although there were Palms and PocketPCs at the time. With the cell phones we had to set up the HTML code so that pushing buttons on the phone would trigger the app…..there was no touch screen.
Today it is a different world. Just about any website can be view rather clearly and nicely on smart phones and tablets. So why do mobile development? The main reason is because mouse actions (events to a programmer) are quite different than touch actions (events). Take a dropdown menu for example. If a person using a mouse hovers over a menu with sub-menus, it often expands automatically. This makes it so a user doesn’t have to click on the menu to view the other options and well, how is a user supposed to even know more options exist? By clicking on each top level menu item? Well, there is no “hover” on a touch screen. It can be faked, but in reality, it just doesn’t work. Usually dragging a finger around on a touch screen moves the screen around or scrolls the browser window. It is quite different than using a mouse.
So what to do? Well, you can do one of two things. Write one website that accomodates for both types of uses or write two websites, which if done correctly is just one website with browser detection that alters the css and JavaScript for the given device. A menu example for this would be to make it so the top level menu item isn’t a navigation item when clicked. When it’s clicked all it does is expand the sub-menus. This way, if a mouse hovers or clicks on the top menu item, a menu expands. If a person with a touch screen touches the top menu item, it behaves like a mouse click and expands…..but you want it to stay expanded so the user can touch the menu item they want to view. If the user touches the top navigation again, or selects a different top menu item, the open menu closes. Now we have one menu that works for both types of users.
The only draw back is that a person using a mouse can’t click on a top level menu item to navigate to a page. The thing is, usually the page is just a page that references the menu items or has an overview of that section. This really isn’t needed most of the time, thus losing that fuctionality is not all that much of a loss. Many times I find myself wondering what to put on that page…..and would rather it only be a menu item that expands sub-menus.
Menus are just one example of why you want to develop your site for mobile devices. There are many actions a user does that is quite different depending on whether they are using a mouse or a touch screen.
I personally think that future webpages will be developed to behave more like a touch screen, even if used with a mouse. The more and more people move to tablets and smart phones as their primary use of the Web, the more likely sites will be developed to be touch screen optimized……the mouse will just have to act like a finger and who knows, it might go away altogether…..we’ll see!
When it’s time to decide to build or update a website, it’s not as simple as it used to be. In the old days, you know……10 or so years ago….you really only had a few choices. But today, there are so many options and 100’s of platforms to choose from. So how the heck do you decide what to do and when you finally make a choice, how do you know it’s the right one?
Not all web sites are created equal. Because of this, what you choose depends a lot on what you want your website to do. There are 3 very popular options out there right now, and quite a few other less popular ones that I won’t mention here.
Static Website: Simply a website that is coded and can not be altered or changed dynamically. There is no backend database connection and no CMS driven content. In order to make a change to the site, you need a web developer, or in some cases a program like Dreamweaver, to change it. Good uses for a static website: Marketing or branding site, Personal web page, or any small website that doesn’t change very often.
Custom Database Driven Website: This would be a website that has a lot of custom code to do specific tasks. Many times these types of websites can be complex applications to do very specific tasks. A database contains much of the content that is displayed on the website. When the content in the database is changed, the website is updated with the new content automatically. Good uses for a Database Driven Website: Banking application, online shopping site, social networking site, or any website that is designed for a specific purpose and likely has users who log onto the website to use it.
CMS (Content Management System) Driven Website: These are becoming more and more popular. Essentially this is a Database Driven Website where almost all of the display content, text, images, menus, and so on are managed by an admin module (usually and admin website that can be logged onto to make changes). There are many CMS applications out there, all the way from complex enterprise systems to easy to set up and use OpenSource options. These can be a combination of things depending on what CMS application is used. Some CMS applicaitons are designed to have product catalogs built into them or other complex processes. Others are much more simple and designed to do basic display functionality. Then there are the OpenSource ones which are usually free and have developer community that make many plug-ins for them that will do all kinds of neat stuff.
The choice is not an easy one to make. I see companies make decisions that they later regret because they didn’t realize what they were setting up in the first place. There are also a lot of companies who make web application platforms out there with an aggressive sales force that try to convince you that their product is the best, but they are out to make sales, not help you decide what is best for your business.
I offer services that help you through this process. I look into what you are trying to accomplish, or what you have been accomplishing so far, and can help you sort out what will work best for you. The importance here is that my opinion is objective since I am not tied to any particular software product. It is important to have someone help you through this process who isn’t trying to sell you their product and/or put their developers to work. Trust me, the up front cost to make sure you choose the right path from the start will save you a lot of money down the road.
Feel free to contact me if you want to learn more about the consulting services I offer.
Far too often do I have thoughts and ideas and far too often they go into thin air because I don’t write about them. So here it is…..a place I can spill the beans about what I have learned from 15 years of web application development.
A lot has changed in 15 years. The Netscape vs Internet Explorer days are gone. AOL is no longer the primary way people access the Internet. Google, where the heck did they come from?!
I remember worrying about bandwidth and reducing image sizes to a point where jpegs where not only lossy, the looked lossy too. Yeah, some of you don’t know what lossy compression is……but that is okay…..keep reading anyway. We now live in a day of broadband Internet, mobile devices, and believe it or not……websites on TV Screens! At least this time around it’s HD TV screens so web pages don’t look to horrible on them.
I remember hearing someone tell me JavaScript was a dead language. Of course that was before jQuery came around and long before Steve Jobs (RIP dude!) said the iPhone and iPad will not support Flash. JavaScript is here to stay, at least for quite a while longer.
There is all this talk about HTML5 and CSS 3……finally the w3c is pushing for some new technologies. Unfortunately Microsoft is once again the troublemaker with it’s Internet Explorer browser……..they just don’t keep up and make life easy for us web developers!
This blog is here for me to talk about all this stuff and more! 15 years of it! Just keep in mind, there are a lot of developers out there and many with their own opinions on things……..mine is just one of the many out there. So read my stuff, enjoy it, and hopefully you get something out of it.
I have a friend who is a chiropractor. She is pretty cool and upbeat. Her offices are in Uptown which is a hip little area in Minneapolis. The thing that is cool about her business is that she makes it fun. She jokes around, smiles a lot, and it is very obvious she likes what she does.
She asked me if I could redo her website. I told her I would be happy to do her website, so we went back and forth on what to do and how to design it. She told me all these ideas and what she wanted changed from her old site. Being that I am a busy person and I was doing this as a favor, I didn’t have a lot of free time to devote to her site. A few months passed and I wrote up some sample pages. We went back and forth on what to change and made adjustments and so on. While we were doing this I ended up on a contract doing a website for a marketing firm called Hunt Adkins in downtown Minneapolis. During that work I was asked if I could make their blog look like their website. I didn’t know much about how their blog was done, but I said I am pretty sure I can do it since I know that most blogs allow access to the CSS and basic HTML template of the blog. Little did I know, the blog was in WordPress.
So not knowing a thing about how WordPress works, I dived in and started looking at the code. If you don’t know, WordPress is written in PHP and you can download all the source code at wordpress.org and have at it. I found the CSS and the basic HTML template code fairly easily and since I use Firefox’s Firebug tool, I was easily able to find out what CSS was giving the site it’s look and feel. In about 4 or so hours time, I had the blog looking like the main website with top navigation, footer, and everything else looking the same. I was blown away by how easy it was.
This got me to thinking. Moe has a very dynamic business. Things are always changing and services and employees are always coming and going. I realized that if I built her website using WordPress, I could have ultimate quick easy access over her website content. So I talked to her about this and within short order, I had her website up and running using WordPress.
http://www.moebodyworks.com
This is with a full menu that included all the services and bios of all her employees that she wanted. The best part is, her site is what I call a work in progress. It is up and very functional right now, but we can continue to add features and more pages as needed. If she adds a new service to her business, we can quickly add it and keep her website up to date with her business.
As I work with WordPress more, the more I find it useful for building websites quickly. The site can easily be skinned to look how a person wants it to look. They can have pages and content added in minutes without any code being written. I won’t do all my site in WordPress, but where I find it useful I am certainly going to leverage it’s CMS like qualities and build out websites that allow a company more control over the content of their website.
This is one of those discussions I have seen go on and on and on…. Mostly in web development forums. I will start off by saying one thing about web development forums……not everyone on those forums is experienced, nor do many of them have a long professional history developing websites for many companies and a wide variety of projects. It is time to stop relying on them for important information. Can they be helpful sometimes? Yes, but don’t take what is said in a development forum as valid until you do a bit more research, usually through cross-referencing what you learned.
Okay, so let’s get back to the “when to use tables” discussion coming from someone with over 15 years of professional web development experience.
Tables were created, think Excel, to contain cells of content (or data). In the early days of HTML, developers learned that if they wanted their page sections to remain where they needed them to, usually in the form of rows and columns, they used a table “layout”. The word layout is key here. The table would actually be what structured the web page. A header section would be a table “row” that spanned across the entire top of the page. Then below it could be columns (cells) with one at the left or right that may contain navigation or other info. A table could easily create a 2 or 3 column layout, or more if needed. Then adding a footer was just like adding the header, just span a row all the way across.
Basic web page layout using tables
| Header |
Left columnNavigation
- Link 1
- Link 2
- Link 3 |
Middle |
Right column |
| Footer |
Back when monitors where 800 x 600 or 1024 x 768, the page content took up the entire width of the screen and as the screen was resized, the content would flow naturally within the cells. Table layouts were very useful.
As we got into the 2000’s CSS started to become more of a standard. It was nice to be able to format how a page looked outside of coding attributes within the elements themselves. But not only that, CSS had the power to size, position, and even add behavior to elements, more specifically the <div> and <span> elements. Many page designers started using the <div> element and CSS to do page layouts, thus breaking away from the limitations of a table layout. Now a site could look however a designer wanted it to look. Elements could be positioned anywhere on the page and even layered on top of each other. As browsers become more compatible to CSS standards, this type of layout started to become more common and allowed for a broader range of layouts.
The bad part was the lack of standards on how web developers did CSS <div> layouts, thus many web pages were hard to view and navigate, let alone look the same in all browsers. But today, there is a general standard that most developers follow. Because of the wider style monitors it has become a near standard to have a fixed width web page that is centered on the screen. Usually the width is 1000 pixels or slightly narrower. This is because there are still a lot of monitors that are 1024 x 768, so a 1000 pixel wide website will fit slightly within those screens. The outer most element is usually a div set at 1000 pixels (give or take) wide with an auto margin to the right and left, allowing the page to always be centered regardless of screen or browser width. If a browser shrinks below this width, a horizontal scrollbar shows up at the bottom, instead of the content getting crunched into the smaller view.
So it is rare that a table is used as the primary layout and one shouldn’t be used any more. But there is still a use for tables, so don’t get rid of them entirely. Tables are nice for displaying data in rows and columns, just like how Excel and other data type applications do it. So that is one use of tables that is very helpful. With HTML 5, as browsers start to support it, we will be able to scroll the inner content of a table while keeping the headings and footers in place, which will be nice since sometimes there can be many rows of data that won’t fit on a screen.
So what about layouts? Is there any use for tables there? Well, the simple answer is, yes! What if you have a section of your page that has 2 or more columns and as one column gets taller, you want the columns adjacent to it to also grow at the same height? This is common and well, a table layout will automatically do this adjustment for you without any added coding. I have seen web developers use complex JavaScript to keep columns lined up and all the same height! Why?! This is just a lot of extra work when a table will do it automatically. You see, sometimes web developers get it stuck in their head that tables are bad, so they refuse to use them. Tables do still have a place and when they are useful, feel free to use them. When I go to a page and see 7 nested divs to accomplish a layout that looks like a classic table layout, I want to start pulling my hair out!
But, I am not done yet. I have a suggestion, especially since I found out about a cool CSS display feature. If you have a wrapper div you can set the css as “display:table”. Now that div will act like a <table> tag. Now you can create a div within the wrapper div, sometimes called a inner-wrapper and set the CSS to “display: table-row”. Now you have a div nested within your wrapper div that acts like a row (inner wrapper). Guess what, it’s column time! Yep, put 2 divs inside the inner-wrapper div and set the CSS to “display:table-cell”. Throw some content in the 2 divs, then style up some borders if you want to see what they look like. You will get the 2 divs side by side that act just like table cells. So if one grows taller because of size setting or content, the other will grow taller with it. You simply have divs acting like tables, but with a lot more flexibility and if in the future the layout changes, the CSS can be changed, removing the table behavior and altering how the page behaves.Now that I learned this CSS <div> table functionality, I never use tables for layout purposes. I will only use them as data containers for display content within a layout, likely content coming from some back end data source. If you ever need table row type behavior, likely because you want multiple columns to match heights, use the CSS way of making divs behave like a table.
There you have it. Get away from those forums and stop arguing about whether a table layout is better than a CSS div layout……because table layouts are dead! Okay, well….sort of.
