Type: HTML5, CSS 3.0, Javascript, Responsive web design using Foundation, Photoshop, Illustrator
The last time I did a complete remake of this website was in 2004 and, even though I was very proud of the design at the time, a lot of things have happened in web design in the ensuing years -- particularly in the advent of designing for a multitude of screen sizes, from iPhone screens to the popularity of 27-inch monitors. It was time for a change.
Why have a website at all?
This is a fair question. After all, with LinkedIn and Facebook and all the social sites out there, why do I need a personal website anymore? I need a place where I can demonstrate my abilities. For most of the past decade, I have worked for companies on their private, internal sites, which aren't accessible by the public. LinkedIn and Facebook don't give me the ability to show off samples of designs or code I have created.
For example, I can talk about doing Responsive design all day, but only on my own personal website can I display this ability, as well as give you the opportunity to peek at the actual code.
How I came up with the initial design
I had a lot of ideas for designs. At first, I wanted to be really inventive. I originally wanted to actrually "draw" the site on the screen, using the new HTML5 Canvas capabilities. I planned to make the page look like a top-down view of an old Xerox photocopier. It would have an old-style LED panel with the current page choices. You would pick a page from the LED panel then click a big green button, which would then deliver a page printed in Canvas. It was a cute idea, but would have only worked on a computer monitor. It wouldn't have worked at all on a small, mobile screen.
Then in the spring of 2012, the first version of Foundation from Zurb was released. It was the first framework for prototyping Responsive web pages. I was genuinely sold on it from the start. That's not to say that it is perfect. As I created the remade website, it was in version 3, but it still lacked one important thing: adherence with some of the new elements of HTML5, such as the new "header," "nav," "section," "article," "aside" and "footer" tags. Foundation relies on class tags being contained in div tags. I'm hoping a future version of Foundation learns how to use the new HTML5 elements. In order to bring myself up to speed when that happens is by giving each div tag an ID that is appropriate for its HTML5 element name. You'll be able to see this if you look at the source code of any page on this site.
Once I decided on doing Responsive design for this page, I decided to make the design adhere closely to its 2004 look, primarily in continuing to use my signature as a design element. Sigatures have long been used for logos in marketing, going back to the use of Spencerian script in the 19th Century. To this day, Coca-Cola, Ford, Johnson and Johnson and other companies use Spencerian script in their logos. It gives their brands a personal touch. I used a signature I drew with a Sharpie marker for my own signature for the 2004 makeover. Then I animated it using GIF animation (which you can see on my old site at ahinds.com). If you compare the two, you'll see that the new version is much bigger than the old one. I didn't simply blow up the old one -- I recreated it. Using Adobe Illustrator CS6, I traced the final frame of the GIF animation. The new tracing tools in Illustrator are exceptional, giving me the ability to preview and perfect the results until I was satisfied with it. The version you see was conversted to a PNG, but it's my intention to use the Illustrator vectors to turn it into an SVG and eventually turn it back into an animated, self-drawing logo eventually.
One thing you'll notice is that the top of the copy overlaps the descending characters of the logo. This requires a little Javascript algorithm that I employ when the page is being loaded. I wanted the page copy to overlap only the descending characters of the logo. It works pretty well, but is not perfect, and I'm still trying to perfect. Here is the current code:
Button button, who touched the button?
In the original version of this website, created during the spring of 2001, it was full of big buttons for links. For the remake in 2004, the buttons were gone, replaced by simple text links, unmarked by any decoration. Now big buttons are back -- because of mobile. It turns out that simple text links are too hard to click on a mobile device, especially with a thumb.
That's not to say there aren't any text links. I have links throughout the Project and Code sections of my site, but they're usually long links to other web pages and separated by vertical linespaces in order to set them apart from other potential links.
One thing you'll notice about all versions of this site is that there are no dropdown links. Why? I hate 'em. I'm familiar with them and I'll create them if I'm forced. But I have always found them to be one of the most un-intuitive things on a website. After all, your browser already has a menu bar with a dropdown menu (except new versions of Internet Explorer -- those folks at Microsoft are in a Fantasyland of their own these days). If browser-makers had wanted you to create your own dropdown menus, they would have created an HTML tag to help you out.
Here's what I believe in: A top navigation for main sections and a side navigation for items in the current section. If there are further subsections, clicking the side navigation button will take you to a menu page. Otherwise, clicking a navigation button will take you to the most important page in that subsection. Sure sounds simple and intuitive to me. That's the approach I take in this site.
It's also important to consider mobile in all of this. If you do a dropdown menu in mobile, just how are you going to display a long list? You could use a SELECT list to do so, but those look unsightly on a regular computer screen -- everybody these days want to do computer screen dropdowns with list elements. Besides, dealing with SELECTs or list elements force the user into extra clicks and increases the possibility of mis-clicks, which are particularly infuriating on a mobile device.
I like the options Foundation gives me to deal with a side navigation bar. On a computer monditor or large tablet, the side nav of my site is placed on the left side, with the main body copy on the right side. But on small screens, the nav readjusts itself to the bottom of the page. This magic is performed by the placement of the DIVs on the page and a special Foundation class. If you look at the source code of this page, you'll see that the side nav (with the ID of "nav2") is actually located below the main body copy DIV. A barebones version is displayed below:
Normally, pages with this particular DIV placement would display the main body copy on the left side and the side nav on the right side, but notice the class names assigned to the "article" and "nav2" DIVs. The 12-column-based Foundation system creates two actual columns in the "section" DIV, one that is 2/3rds of a page wide and the other that is 1/3rd of a page wide. The additional classes -- "push-four" and "pull-eight" -- let Foundation adjust the position of the columns when viewed on a regular computer screen. When readjusted for mobile screens, the position of the DIVs falls back to their hard-coded configuration.
The problem with Retina screens
Earlier, I had mentioned that I had the idea of using Canvas to build the entire site. But I didn't explain why I nixed the idea. It is because Apple announced a Retina display for the 2012 iMac. I knew when I heard that, my plans would have to change.
Why? Because if the user changed the zoom level of ths page, it would look awful on the page. In fact, a lot of things were going to look awful. Sure, as of February 2013, when I'm writing this, there still aren't a lot or Retina screens being used out there, but it's coming. (Remember when Apple was chided for putting USB slots in computers? Just try to find a computer without USB today.)
The days of 72 dpi Photoshop-created graphics are over. I have a couple of dot-matrix graphics on this site, but there will come a day when there are none.
Look at the icons in the buttons at the top of this page. Do they look like they're Photoshopped? Now zoon the page -- all the way up. Those icons didn't degrade, did they? That's because they're not bitmapped graphics -- they're vectors.
In this particular case, they're part of a font I created called "alhIcons." Whenever I need another icon, I open Adobe Illustrator and create an icon using Illustrator's vector drawing tools. Once that's done, I open a font-creation program called FontLab Studio and paste the vector into a specific character. I regenerate the font and then run it through an @font-face generator at fontsquirrel.com to create all the different versions (.eot, .ttf, .woff and .svg) I need for any browser my visitors might be using. Fontsquirrel even generates the CSS code I will need for the web page.
Of course, doing this as a font is easy for me because I've been creating vector fonts since 1995. The advantage of using fonts is that @font-face is compatible all the way back to Internet Explorer 6. Resizing of changing an icon font is just like resizing any font character through the DOM. But there is a downside to creating icons with fonts: they can be only mono-colored. Only Type 3 fonts were multi-colored, and none of the @font-face font formats conform to the Type 3 standard.
If your visitors are using any modern browser including versions of Internet Explorer of 9 or greater, you would be better off using pure SVG instead -- which I would have done, but I wanted to show off my ability to do this with a font instead.
I think there is something we can all be thankful for regarding Retina displays. It will finally end the days of the "Photoshop web developer," who thinks they can have a career in web development simply because they can design and cut up Photoshop documents and save them as HTML.
The case of the Disappearing Label
One other thing to notice about the main sections listed at the top of the page is that when the page width approaches the width of a small mobile device, the text labels disappear, leaving only the graphic icons.
This is accomplished with a simple Foundation class -- hide-for-small -- applied to the text part of the label. It's one of those things I could have accomplished with Javascript, but Foundation makes it too easy to do it any other way.
The Side Nav
Once you have navigated away from the home page of the site, a side navigation panel appears on the left side of the page. As I've already mentioned, I hate dropdown menus on web pages, so this side nav is a nice replacement for that. But there's also another reason for the side nav -- readability. Coming from a newspaper background, I have long known about the necessity for readability in print pages. I was taught that newspaper column widths shouldn't exceed about 24 picas. Beyond that width, readability suffers. Yet, on countless web pages you'll see column widths spanning the entire width of the screen, making the stories virtually impossible to read. By adding a left nav bar, I can further cut down on the width of the main column, making it easier to read.
Making the left nav responsive is easy in Foundation. If you look at the HTML code, you'll see that the left nav DIV is located below the DIV for the main copy of the page. Typically, in a relatively positioned section, the navigation section would be located above the main copy in the HTML. Foundation created "pull" and "push" classes in order to fix this problem. Because of "pull" and "push," the nav can be written after the main copy in the HTML, letting the left nav fall to the bottom of the page when displayed on small devices.
Creating a Very Simple CMS
The Projects and Code sections represent the most sizable portion of this website. I found during the last remake effort in 2004 that it would be valuable to include snippets of code I had developed, not only for my own coding efforts, but tp also demonstrate my abilities to potential employers. I started out with about 30 pages of code, but I could see this effort potentially growing to epic proportions. Hand-coding all this data would take lots of extra time in order to make pretty, so I started thinking of creating a very simple content management system.
But I discovered there was no such thing as a simple CMS -- at least, not as simple as I wanted, so I gave up on the idea. I developed a system in which, I would write the documentation as a text-only document and read it into the page via AJAX. That system worked pretty well until I got a complaint from a potential employer. Because I was simply reading in the text line-by-line, my system dropped all the tab characters from the code examples, making the code more difficult to read. A potential employer saw this lack of hierarchical structure and asked me, not kindly, "Don't you know how to structure Javascript on the page?" He was not interested in my explanation and didn't hire me.
So I went to work on creating my simple CMS. I wanted to maintain the simplicity of my original, creating the documentation in text-only documents with no HTML code added. Since the only complaint I had gotten was about the structure of the code samples, I delimited the code sample from the documentation simply using two pipe characters in the lines preceding and following the code sample. With Javascript and AJAX, I read the document line-by-line. When it encountered the pipe-character delimiter, it read the following section and added either a a textarea input section (for multiline code) or a text input line (for single-line code). In order to fit the code perfectly, it counted the number of lines of the code and adjusted the textarea rows to match. The hierarchical structure was preserved by changing each tab character to five spaces.
This allowed me to write the documentation in a simple text editor completely without any HTML code mucking up things and making them unreadable.
Everything in the Simple CMS is on a paragraph level. My text document looks something similar this (I've added line numbers to help you understand the documentation below):
You can follow along in the processText script of the projects.html page.
-- The first line of the document is placed in the "pagehead" DIV and encapsulated by an H3 tag. (Line 01)
-- Any blank line outside of a code textarea or text input is disregarded. This lets you more easily read and write the documentation. (Lines 02, 04, 06, 08, etc.)
-- The rest of the document is styled line-by-line and then placed in the "article" DIV. (Lines 03 through the end)
-- Any line with a first word of "Type:" is turned into a paragraph, with both a bold and italic tag. (Line 03)
-- Plain lines that don't meet any special criteria is simply turned into a paragraph. (Line 05)
-- Text that is encapsulated in double pipes on lines are turned into textareas (for code longer than one line) or text inputs (if the code is a single, short line). Any code inside the double-pipes is formatted exactly as displayed and changed to a monospace font. (Lines 07 through 11)
-- If a line of text contains alphabetic letters in all caps, it is turned into an H5 subhead. (Line 13)
-- A line that begins with the words "Click here" becomes a link when combined with the URL contained on the next line. (Lines 15 and 17)
-- A URL that is not associated with a "Click here" line is interpreted to be a graphic file and is displayed as such. (Line 19)
-- To add a caption for a visible graphic, simply start the line with the word "Caption:". The Simple CMS will delete the word "Caption:" and style the line as a paragraph italicized. (Line 21)
And if you've followed along closely, you're going to ask the question, "What if I want to style individual words to emphasize them?"
The short answer is: You can't. This is where coming from a newspaper background really comes in handy. In the age of newspaper writing before the advent of personal computers, you simply didn't add boldface or italics to individual words in newspaper stories. These stylistic touches were difficult to add, so most newspapers simply avoided them. This is my homage to those times.
And adding those stylistic touches would start preventing my Simple CMS from being so simple, wouldn't it?
Why is there so much deprecated code here?
I've been developing web pages since 1995 and so, admittedly, there is a lot of code that looks awfully useless here. One example is the code I used, very briefly, to make rounded corners in the bad 'ol days before HTML5. That particular method is never coming back.
But, surprisingly, some stuff does come back. For example, I tinkered with SVG way back in 2004 when it looked like that was going to be a hot technology. Adobe, in particular, was a huge proponent of SVG technology, making a plug-in that let some browsers interpret SVG code. That all ended, of course, when Adobe purchased Macromedia in 2005 and took ownership of Flash, enjoying a few years of financial success with the technology, while letting SVG whither on the vine.
Things turned around for SVG when the technology was made part of HTML5 and is enjoying growing success. To their credit, Adobe never completely let go of the technology in its Illustrator program, which can still be used to describe the vector points for both SVG and Canvas vector illustrations. As a result, my early experiments in SVG are as appropriate today as they were in the early 2000s.
So deprecated code never really dies. It either comes back or it makes for a good laugh.
Welcome back, my friends, to the show that never ends
The first thing about Javascript frameworks that got our attention was cool galleries. We had lots of photos and with Javascript frameworks, our ability to show the photos in cool ways was all the rage.
There was, of course, one drawback to using frameworks. We were OK as long as we didn't want to make any adjustments to it. If we wanted to make practically any modification to the gallery, it will inevitably take longer than it would have if we had created it in Javascript in the first place.
So when I had to construct a gallery for this website, I opted for a Javascript-only solution. You can see the results on three pages of the Design section: Web Design, Web Graphics and Print Design. On those pages, to see the large-size version of a graphic, click on the thumbnail. Once you do that, a darkened, but transparent overlay will appear and the larger version of the graphic will appear.
Here are the basics of how this is accomplished:
1. Create a separate "overlay" DIV. Here's a sample:
2. Resize the overlay DIV so that it matches, at minimum, the height and width of the page (borrowed from the Lotus Notes and Domino Application Development wiki):
3. Compare the page size to the image size and resize the overlay DIV to adjust for screens that aren't as large as the large graphic. Although most graphics will fit just fine on a regular screen, phone-size mobile devices will need an adjustment:
To dismiss the overlay DIV, give it an onclick command to the DIV to set the display style to "none."
Fonts
There are no "standard" fonts in this project. As mentioned earlier, all of the icons are those produced with the program FontLab Studio and recreated on the web page with the following CSS:
An interesting thing to note is that I had tp list the font formats in precisely this order for them to work correctly. If I listed them in a different order, the browser would give an error message that it couldn't "find" a specific font format, causing it to fail. I found there were also difficulties finding some characters. I inevitably made things easier on myself if I limited it to the old-fashioned. 256-character ASCII set, even though the page was capable of the full UTF-8 set.
All the other character sets are from the TypeKit library, which is now owned by Adobe. I got access to all these characters as part of my Adobe Cloud membership, which I recommend highly. It give me full access to the latest version of Acrobat, the Adobe Master Collection (including Photoshop, Illustrator and InDesign) and other cool things. I recommend it highly.
Things to come
It was nearly nine years between the creation of the last iteration of this site and this makeover. It will likely be fewer than nine months before the next makeover.
Nine months?
Yup. You see, just a week before I made this site go live in March 2013, the company Zurb played a nasty trick on me. They came out with a brand new version of Foundation. While this site is built on Foundation 3, version 4 was introduced one week before I went live.
Foundation 4 will likely be superior to version 3, but I couldn't put things on hold for the time it would take me to update this site.
Instead, Foundation 4 will give me an excuse to make one important universal change to the site. The next remake will allow for the display of the entire site in one, single page. I've accomplished this before, actually twice before, in projects for General Dynamics.
And like those projects, I'm going to be able to display my ability to gather data on the fly from both JSON and XML databases. I'm still going to use my own Simple CMS as well, making the writing of the master pages of each section easier as well.
The only thing I don't intend on changing is the actual design of the site, but I might change some colors around in order to be able to tell the two sites apart, but that might be all that doesn't get changed.
Here are some other things that will likely change along the way:
Video editing: I have a section on my video work, which doesn't have anything in it yet. That's because, I have no HTML5 video-worthy clips yet. Most of my video work from the mid-2000s is low-bandwidth Flash versions. I need to convert all those tp MP4 versions, to be played with the HTML5 VIDEO tag. Until that time, the Video Editing section will link to the old video website page.
The Canvas crawl: As described on the page for "Using Canvas to Display a CNN-Style Ticker," I created a crawl for the MIT Lincoln Labs CTO site to display such a crawl on the home page. I hope to soon create a similar device on a web page on this site to demonstrate the ability.
Tag clouds: Currently this site has no search capability. I want to do something different with search, using tag clouds instead tp link to pages that discuss a certain capability, such as Javascript, and display my competency by showing the name of the technology in type sizes in a size relative to my experience. It should be helpful.