Showing posts with label web design. Show all posts
Showing posts with label web design. Show all posts

Sunday, December 6, 2009

New Website In Production

In my last blog entry I wrote about learning Drupal (the web-content management system tool) and that I am rebuilding my website in it. Right now it only lives on my iMac at home but soon I will be relaunching enginpost.com and moving my blog over to that site. In the mean time, I am fairly happy with what I am able to do to build a very stylized gallery in Drupal.

These sample images show what the basic site will look like but I want to focus on the gallery.

Intuitive URLs

First, replace "localhost:8888/ep" right now (in your mind) with "enginpost.com" and check out the address to get to the gallery on my site:
The nice thing about clean URLs is that it makes content on your site quite memorable and less cryptic, which I prefer. So, once I go live, if a person wanted to check out all of the images in my gallery they would type in: http://enginpost.com/gallery


Here is a screen grab of the gallery page on the site will all five images I have uploaded (click the image to view a larger version.) I designed it to make each image look a bit like an old photo. No more than six images to a page and if there are more than six images then at the bottom of the images you get a "pager" which uses Ajax to move you through the images in groups of no more than six at a time.

Instant Sub Galleries Via Tagging (Taxonomy)


Next up, I like to take a lot of photos and currently I use flickr to manage all of that, but I am only allowed so many uploads per month. So, since I manage my own site (as well as pay for the space and bandwidth) I am going to start moving all of my images over to my new gallery. No more being spread across flickr and blogspot and enginpost.com for me. I will be all in one site.

The next important task in creating my image gallery is being able to easily tag the images and then find them again by searching through those tags (if you are not familiar with tagging, it is like labeling or indexing your images based on ad-hock categories. Said another way, imagine that you took a picture of a friend during Thanksgiving. Well, you might want to tag that picture of "frank" with the terms "Frank" and "Thanksgiving." Later you will want to search for and see all of you shots where you tagged "Thanksgiving" you should be able to pull up that image.)

Now, check out this URL. It is the same as above with the addition of "/scottish"

The idea here is that I can pull back only the images where I have tagged them with "scottish." In this case I tagged only 4 of the 5 images I uploaded (for testing) using that tag. So only those images come back!


Make note that the gallery title says "Gallery: (Scottish)" this time and not "Gallery: (All)" like it did in the earlier image (click the image above to view a larger version.) I am doing a couple of tricks. First, this is the same exact gallery page in Drupal. In fact it is the same basic core page for my entire web site but I have themed just the output of the images here so that they look like old photos. Second, Drupal is reading the URL to figure out if it needs to filter the results based on the tag term I put on the URL. When I themed the image content coming back I just did a little trick to be sure it capitalized "Scottish" even though it isn't capitalized in the URL. This way everything looks nice and consistent and professional.

Larger Image Versions Using Lightbox

Finally, just as I have been asking you to click these images to view a larger version, I wanted that same feature in my web site. I have noticed that people are using a technique these days which opens a larger version of the picture on top of the existing page rather than opening a different window, and I think that looks great. It is really the new standard for how site galleries operate so I went looking to see how that was done.

In the end I was able to pull this off quite easily in Drupal. In addition to that I was able to setup an image processing module that would take the huge images I was uploading and it created thumbnails and standardized large view sizes to make the gallery images incredibly consistent!


Notice in this image that you can also download the original image in it's even larger size once you have clicked to view the larger version. Beautiful! I also made it so that when you click one image to make it larger, it automagically starts a slideshow of any remaining images in the group. You can stop the slideshow at any time or manually advance the slideshow as well.

Drupal sure makes this stuff easy. If I had to do this sort of thing from scratch I don't have a clue how long it would take me to build out all of this functionality. In addition, the site design is completely mine (so one wouldn't necessarily assume this was a Drupal website by looking at it.) Beyond that the time I save now by allowing drupal to create thumbnail and standard larger views of my images more than makes up for the time it has taken me to learn how to do this stuff!

Very exciting geekery!

The Difference Between My Brain And A Web-CMS

That title is a joke. I am nothing like a web-content management system and so comparing my brain to the purpose of one is ridiculous. But I have been bashing my brain against one particular web-cms for a while now and while my head hurts from the steady rate of growth and discovery, I can say that the experience has been, well, glorious compare to the learning curve of other kinds of technology. I am talking about the web-cms Drupal.

I have learned a number of other languages over the years: Visual Basic, Cobal, Powerbuilder, Foxpro, C, Objective C, C#, .NET framework, Cold Fusion, PHP, ActionScript, JavaScript, Smalltalk and a few others (fhew!) The thing about most programming languages: it is a lot like riding a bike. There are many kinds of bikes out there, single gears, multiple gears, road bikes, trail bikes, and while they all ride differently, once you learn one the others implement the same basic expected functions (pedals, breaks, gear switching, turning, etc.) just not in the same way (rod-based gear changing, twist / crank gear changing, breaks on the handlebars, breaks on the pedals, etc.) With most languages the purpose remains the same, the tools to get you there are what change a bit.

Diving over into a web-cms is like tweaking a bike for a particular purpose. The seat, the handlebar grips, the shoes, did I mention the seat? A web-cms can implement many different approaches based on the technology (or programming language) beneath it. This means you need to know a bit about the programming language it is written in, but then you need to know how they used that language to put the whole thing together so you could snap it together in a custom manner: enter headache.

Drupal, the web-cms of my choosing, is really built on the best of the best. Allow me to throw out a few buzzwords: apache, MySQL, PHP, jQuery and Ajax. And Drupal sites tend to look amazing in old browsers as well as new browsers, index really well on sites like Google (sidenote: it is funny to think of a monolithic entity like Google as fundamentally a site) and plays really well with other technology. If Drupal were your kid, it would never disobey, would be infinitely creative and filled with potential, and you would never have to tell it to clean it's room.

Drupal is clearly the premier poster-child for Open-Source-Gone-Well. It nearly defines the phrase. Drupal is open source in that Drupal version 6 (the current version) included the participation of over 700 developers world-wide devoted to making this community product better.

And the magic of Drupal is in the contributed modules. These are little optional pieces of downloadable functionality, all open source, available for the purpose of adding functionality to the core web-cms that is Drupal. Do you want a site to run your personal blog? Core Drupal does that. Do you want to setup a community calendar and a photo gallery and manage document libraries with sign-in & sign-out capabilities? Go visit http://drupalmodules.com/ and you will find all of the Contrib. Modules you need to pull that off.

Learning Drupal is, however, just a bit sketchy, but not in the way you are anticipating. It isn't that Drupal information is difficult to find. On the contrary. There is too much information out there. And self-published experts range from goofy to golden-nuggets. The trick is getting good references from community members to find the right best sources of knowledge. In a sea of Drupal there are a few amazing stand-out sources that every wanna be Drupal user needs to find... but I am going to hord those references so you all don't benefit!!

That is joke. The first amazing source is IRC. That's right! I said it! Remember back in the day when AOL first came out and how cool it was to chat with people over the internet? Well, long before AOL pretended to BE the web, IRC was! IRC, or Internet Relay Chat, are these communities of like-minded folks who are chatting it up on various topics. In the Drupal IRC world, irc.freenode.net and #DRUPAL-SUPPORT are your bread and butter. I have received tips from everything from (1) great hosting services, to (2) how to enable features in my custom theme configuration, or (3) great book recommendations.

All in all, my career has taken a completely reborn turn in the last 3 years. I was completely invested in Microsoft a few years ago. If I were to explain my career in terms of technology I would have said: SharePoint, VB and C#, Ajax, CSS and SQL Server. These days, without a doubt I would now say: PhotoShop, Dreamweaver, Flash, ActionScript 3, Drupal, PHP, CSS, xHTML, XML and Design. In the world of tech, that is like agreeing to fight with the English and just before impaling William Wallace on your sword, shaking his hand and joining his team along with the other defecting Irish (not that I am Irish... I am Scottish!)

So I am geeked about the future of my career. I am 36 years young and feel like I am just getting started.

Saturday, November 14, 2009

Busy Days

I've been busy lately with a number of new developments:

Video Work!

At work we have been talking about incorporating more video into our e-learning and marketing products. In some cases we are supplied content. In other cases we need to produce big content, so we will be outsourcing much of that for sake of scale, resources and quality. But there seems to be a number of opportunities to take on small to medium-sized video work.

About a year ago I investing in a nice Canon XH-A1 HD (1080i) 24f pro-sumer camcorder. I love it. The images from this piece of equipment are amazing. But, if I am going to use my camera for these projects, I have decided that getting the "film" look is important.

Recently I purchased a glidecam, which is an in-hand stabilizing device that makes your shots appear to have been taken from a dolly rig.

Secondly, I just purchased a Letus device which allows me to attach my Canon XT Digital SLR lens onto my XH-A1. This allows the camera to shoot with an extremely shallow depth of field (which means that your subject stays in focus while everything closely in front and behind the subject falls out of focus.)

A while back I had already invested in an XLR field condenser microphone and rode boom for the purpose of capturing higher quality audio while on the run.


Click the above image to check out a larger pic!

This next week is the first shoot. Unfortunately I do not have any light gear and investing in a basic low-quality 3-pointing kit (for film) costs around $2k!!! So, if anyone knows of some place with a better price, let me know, so I can get my boss to make the investment.

Updating My Resume!

Specifically, I've been thinking about revamping my website http://enginpost.com for the purpose of "simplification." The current site is quite busy and filled with a level of detail that is, well, distracting.

I am pondering taking on more side work in my free time, so revamping the site might be the way to go. Here is a shot of the new site.


You can checkout prototype (which does nothing yet) at:

http://enginpost.com/cs

Mobile Games!

Lastly, this one here is a completely new venture for me. At work we are talking about building playable games for mobile devices, but rather than learning proprietary languages for each device we are targeting, we have been looking into both browser-based javascript-driven games as well as flash CS5 mobile game development.

For my first javascript-browser-based game, I decided to attempt to reinvent a classic old-console game. I am not done yet, but so far I have been able to master animating a few bits using HTML, DHTML, CSS and JavaScript, and it works on my iPhone!


If you want to check this out in your browser (or on an iPhone) go to...

http://enginpost.com/bomber/bomber-drop.html

When I complete any games I will be sure and post them here.

Saturday, October 24, 2009

desktop wallpaper creation site

I thought I would share this interesting site where people can create a share wallpaper designs using the tools provided by the site. It's a fairly cool site with a number of interesting tools for layering these stamp-style illustrated graphics, sharing your designs and downloading them for use on your computer.

Here is a quick shot of my mac hard at work helping me create a desktop wallpaper:



You can click the image for a closer view.

The site is http://wallpapers.x3studios.com/

Saturday, June 20, 2009

AS-MVC: Hot From the Geekery

In the world of code development, stuff changes all of the time. And when a programming language makes a big change everyone using that language suddenly gets reduced from being fluent to, say, a seven-year-old who is recovering from having just fallen from a tree. You brain hurts all of the time and you can't remember where you left your shoes or how to tie them.

In the Adobe Flash world I have lived through a few of these large changes. For example, Flash used to have a coding language under it that was, well, fairly silly at best. But it was the most interactive language for client-side web development and so I learned it. From that language (I believe this would be back in Flash 3 or maybe 4) ActionScript was born. ActionScript (later referred to as ActionScript 1) added some standardization but also let you write code the older, sillier way. But it was a syntax move in the right direction (they added something called "dot notation" which pretended to be object oriented.) Then along came ActionScript 2.0 which was a move from "dot notation" to a slightly more "object oriented" reality.

Since ActionScript 2.0 a Flash Developer had the luxury of writing code that adhered (mostly) to object oriented development techniques but could also write completely valid AS 2.0 code that had far less to do with Object Oriented Programming (OOP.)

Now we are in ActionScript version 3.0 and that is also quite similar to AS 2.0 but the OOP-side of AS 3.0 is far closer to OOP than flash has ever been. As a result, people attempting to learn AS 3.0 are searching the web for examples of how to build Flash content using AS 3.0 and are running into a mix of OOP techniques and non-OOP approaches. I say OOP approached because Object Oriented Programming to many people comes down to meaning "I built a bunch of classes" but that is a very rudimentary understanding of what OOP is. Saying OOP is "building a bunch of classes" is like saying web accessibility is "adding ALT properties to IMG tags in HTML." To a degree that is true, but that doesn't begin to come close to explaining what 508 web accessibility really is, how it works and all that it encompasses.

If you have made the jump from "timeline" code in flash to "class-based" code then you have surmounted the first hurdle. Again, because you could write non-OOP code in AS 2.0 making the jump into AS 3.0 was like pulling off a motorcycle trick across the wide side of the Grand Canyon. Having at least created classes in AS 2.0 is like having a bigger more powerful bike and simply jumping across, say, the Mississippi River: still scary but you can at least see the other side without squinting.

So, if you have made the first jump (building classes) then here is a hint to understanding some of the rest of the jump.

Now, I don't have the time to help outline all of the new classes or any new syntax here. That is an unavoidable effort at scratching around and memorizing a new framework / code-base. There are no shortcuts to that, but I can say that tools like FlashDevelop can help you find your way much faster since FlashDevelop will add your import statements to your custom classes. The bigger (or at least equally as large) hurdle in making the AS 3.0 jump is understanding the most appropriate approach to coding your classes and how the timeline (or visuals) relates to that code. Most folks don't know how to avoid writing code in the timeline and are searching desperately for what the right best approach might be.

The amazing part about OOP is that there are a number of excellent approaches to organizing your coding effort, but I am going to briefly explain one of the older techniques that remain valid to this day.

Let's look at the Model-View-Controller (MVC) approach to development.

Model-View-Controller is about cleanly separating the three parts of a software development experience: The interface (View), the common utility logic (Model), and the instance of the application and it's controlling of the interface and the utility logic (Controller.) Let's go through each of the three parts.

The View:
In the Flash world, the View is the "front-end" interface where the user is listening, watching, talking, typing and clicking. In the MVC approach the interface would be planned appropriately to break apart the interface into various logical parts: video player, audio player, text presentation, lists, editing forms, common game controls, etc.

In the various Views you might create animations that are completely controlled in code by class utilities like "Tweener" which can be told to animate something from one frame to another specific frame and notify you when that animation is complete. That sort of "control" code is written into the Controller to manipulate various states of a View.
The Model:
The Model is where we put the logic of the application. I previously referred to it as common utility logic because I want to separate in your mind the code that animates the state of an application and the code that provides common services in a very interface-agnostic utilitarian manner. Said another way, you might create a rich internet application (RIA) in flash that retrieves information from an RSS feed for displaying in the browser. In this architecture and approach you would write an interface-agnostic utilitarian class that simply gets that data and hands it over as a result. If you write a class to retrieve RSS feed data (XML) and hand back the results and you keep that separate from any interaction with the presentation / interface / View then you can reuse that code (Model utility class) in future projects that implement different interfaces.

Your custom common utility classes, any other classes you are using in Flash, or classes from some third party are typically referred to as part of the Model part of the MVC approach.
The Controller:
The Controller as you can imagine is also comprised of code. In the AS 2.0 world the controller was typically just a number of functions in the lowest level "_root" timeline in flash. In the AS 3.0 world inside the Flash paradigm of development, the Controller is the Document Class associated with the lowest level timeline FLA. Inside the Flash project properties you can now assign a class to basically be the code that the SWF calls first before anything else. It is inside the Document Class where all of the action starts.
The document class could create an instance from the View (some interface, possibly a login), animate it into visibility and link up code that "Controls" (or watches) for clicks from that Interface, which might create instances of common utility classes from the Model to perform some function. Let's look at one example of what that interaction might look like.

Going back to the previous example, let's imagine someone arrives at your RSS Viewer RIA. Once the SWF loads it would call the code in your Controller (Document class.) The Controller would animate in a presentation of the RSS List View (an Interface element from the library) and then wire-up the list to code, in real time (animate and setup the View for interaction): The Controller might use a class from the Model to get the list of RSS Feeds and then populate the View with that information. The Controller might dynamically associate a mouse-click event with the list.

Let's imagine that the user mouse-clicks on an RSS Feed item presented in the RSS list View. The Controller would be notified of that click (because it wired it up a moment ago) and would then need to present the RSS Feed Reader View (yet another View inside the View part of the MVC approach.) Before it does this you might have written the Controller to clean up the List View by unloading arrays or removing event watchers that are no longer needed.

Once the RSS Reader View was ready, the Controller would wire up that view for scrolling and various kinds of mouse-click interactions.

This is the basic MVC approach to OOP in AS 3.0 under Flash CS3 and CS4. As you can see, it is all about events managed by the Controller resulting in the presentation of new Views and the Controller management of their interactions via Controller code as well as the Controller using other utility classes from the Model but it is all about events.

Naturally you are going to want to get really familiar with the ActionScript 3.0 event model: how do you code for events, how do you handle asynchronous events, how do you author asynchronous events in your custom classes, what are the more common View related events that the Controller needs to manager (for example: setting up a View, managing interactions a user experiences with a View, cleaning up after a View no longer needed in that moment, etc.)

Well, that is MVC and I hope it wraps some context around knowing how to explore AS 3.0 and what sort of architecture and approach decisions you might want to make inyour new coding projects. Have fun and build cool stuff!

Monday, March 16, 2009

webgeekery: highspeed coding for front end behavior

Recently I have been doing quite a bit of work with Drupal. Nothing serious. Just fiddling and getting my head wrapped around CCK and Views and being able to quite create cool complicated HTML website stuff. Tons 'o fun. Anyway. As I am working I keep bumping into a lot of cool presentation end code that acts like a desktop application (well, to be fair, it acts like the coolest of the desktops apps that I have worked with. The way it gets and presents data is typically far cooler than desktop applications... I digress.)

The technology behind all of this front-end eyecandy-like-magic is a javascript library called "jQuery." jQuery has been around for a while now, and I have watched it run with a number of projects, but I have never taken the time to really look into it. Well, I haven't looked into it... until now and now that I have I can say... it is pretty darned cool.

So now I am learning how to write that code myself and I am hoping to start building some cooler stuff using this great library.

Wednesday, April 18, 2007

Why Images As Links Are Better Than Text As Links

This is a hugely debated topic, the biggest argument against this technique of using images as link buttons being that large (kb size) graphic-ladden pages unnecessarily clog the bandwidth. The other very popular argument is the new _old_skool where some people want the web to looks and feel like a circa 1980s BBS. I think I can shed a little light on why I can get all the bang of a thin-web technique with a powerful combo of benefits in usability and SEO (search engine optimization, for any newbies out there.)

One of the most popularly overlooked indexed realities on the web is the graphic, specifically the IMG tag. Nobody is going to create an IMG tag without defining its SRC attribute, but I know plenty of people who do not go back and fill in the ALT attribute (side note: the ALT is an attribute of the IMG tag, and I have heard a number of people refer to the "ATL tag" and when we talk like this we are mixing our metaphors. Technically, ALT is meant to define alternate text definition for the image the IMG tag is displaying. Some people like to imagine that by filling in the ALT attribute they are "socially tagging" their image. While that may be true, most people are actually refering to HTML syntax and not social tagging, so, if you are having a technical discussion about HTML tags, please refer to it as the ALT attribute.) In some cases this actually makes sense. Since a screen reader will read through the HTML tags on a page, if you don't fill in some of the tags for images that create layout but do not communicate something specific, then it might be better to leave the ALT attributes blank. But in many cases it is just more important to go ahead and give an alternative definition to the image. With this in mind, lets consider how a search engine indexes a website.

The most popularly acknowledged technique for a search engine in indexing a page is that a crawler hunts down the "A" tags on a page and associates the text within the "A" tag with the HREF attribute in the "A" tag. Simple, right? What if the "text" inside the "A" tag is an IMG that says "Read Me" in the graphic (I don't advocate this technique in text, since it does not clue the reader into what they would be reading about). What will the search engine index on? If you didn't have a graphic and just had text that said "read me" then if someone did a search on "read me" at google, your link would come up. How horrible is that? Let me tell you. That is bad. So, number one for SEO would be a text link that actually describes what you are clicking on (eg. click to read more about Search Engine Optimization ). But, if you want to use a graphic, then create a single graphic that you can reuse (that the browser will cache and continue to reference without multiple downloads) but set the ALT attribute to something uber-meaningful. This way the search engine will associate your image ALT value with the URL in the "A" tag. You get some very optimized eyecandy with an excellent SEO value to boot.

In terms of usability, remember that people spend the majority of their time on the web looking for something. This is why the statistics show that the largest interaction on the web by an astounding degree is: a surfer hitting the back button. The most redundant and frustrating activity on the web is the negative experience of following a link and then saying to yourself, "well, not what I was looking for" then hitting the back button. You don't want to navigate your users into this black hole experience simply because you gave them links that did not do a good job at targeting/explaining the content at the other end of the link. The best way to avoid this is to optimize the link message. The worst example of this (you can read about this in my blog entry Click To Read More ) is the textual "read more" link. The best is to adjust the textual link to include the actual descriptive message in the link. But if you have a site that would work best if you used a graphical link, then remember to set the most descriptive value for the ALT attribute.