Of Maintenance, CSS Alignment, and Responsive Design

It happens more often than we like to think. Maintenance of existing assets demands a chunk of our time. It happened to me early in the week when a Zendesk help desk issue came in. The startup-I-volunteer-with experimented with a mechanism for getting business news stories submitted. Part of that mechanism is based on the wonderful facilities at Wufoo.com. (If you don’t know, Wufoo is an excellent web-form building and managing site. Awesome interface, service, and support (as you will shortly see) - Highly Recommended!) We (at the startup) embed a Wufoo form into a page to collect “static” information about a company. We then use a bit of PHP and Wufoo’s wonderful API to retrieve any prior submissions and pre-populate the form - very sweet!

Until it doesn’t work…

The form in question has space for LOTS of data. So much so, in fact, that when re-submitted to Wufoo to pre-populate the form, we appeared to over-run a “GET” buffer in the software on their server. Thanks to Andrew on their support team, this was quickly diagnosed, and while there was nothing they could do about it, Andrew suggested that I download the form, host it’s HTML, etc. on our server, and POST the data back to them. Awesome! The form was soon “back online” and working better than ever! Thanks Wufoo and Andrew!


In the redevelopment department, I have been plagued by an alignment issue in the shell for the startup’s next website. The header has an image with the title just to the right of it. As one scales down the viewport - say for a mobile phone, it would be “nice” for the title to move down below the image and wrap appropriately. For the life of me, I couldn’t get that to work “simply”. I had put it down as something I would have to come back to and write media-query wrapped CSS for, when I had more time. Until I did a little searching on StackOverflow… It took a little “tinkering” to get what I wanted, but the technique described here worked wonderfully. You should read the answer and try it yourself. A short description of the technique is that two “inline” elements who both have “height” and “vertical-align: middle” set, will, in fact, be centered vertically in their container. (Like I said - read the answer on StackOverflow…) Now the header “collapses” wonderfully as the screen size gets smaller.


This week ended with another trip to JAX - it’s great to live close to family and “run down to JAX” for a week!

While in JAX, I have been experimenting with making the site I’m redeveloping for my startup friends look good “on the small screen” (as I mentioned above). The “responsive design” additions to Bootstrap have been a great pleasure to use while making the changes. This is a learning process for me, actually. Adding the responsive elements to Bootstrap is as easy as adding “bootstrap-responsive.css” to your page (instead of “bootstrap.css”). Or if you are using LESS, include “responsive.less” after “bootstrap.less” in your project’s main “less” file. This may be all you need to make your site look great on everything from smartphones to tablets to the desktop. But probably not…

What I soon discovered is that a desktop-sized site puts a TON of stuff at the top of the page - stuff the user must scroll past to get to the content you actually want them to see. While we who have smartphones have become accustomed to doing that - after all, “most” websites are designed with desktop browsers in mind, that’s not the experience I wanted for the sites I am redeveloping. I wound up reading Bootstrap’s documentation on responsive design, particularly for “how to leave stuff out” on smaller screens. I also chose to use the “collapse" plugin to make the menu bars "get out of the way" into nice buttons on smaller screens. Take a look at Bootstrap’s example for more inspiration.

So far, I am quite pleased with the result. The little extra effort is making a huge difference in the look of the site on the smaller screen. Highly Recommended!

Of Keyboards, Hosting, Site git Gotchas, and Milestones

On our way home from JAX, we stopped by Sam’s Club to pick up some things for the farm. While there, I looked again at the Targus Universal Tablet Starter Kit (BUS0272). I have an old Think Outside Stowaway Universal Bluetooth Keyboard (XTBT01) that I have used off and on since the Palm Pilot days, so using a Bluetooth keyboard is not a new experience to me. And I am still very happy with the Stowaway - it folds into a small, neat package I can throw into a gadget bag and easily take with me. There were two attractions for the Targus purchase. First, the keyboard. It is small (as you would expect) but, since it is slightly larger than the Stowaway, it has a full keyboard layout that looked awfully similar to the MBP keyboard. When I got it home, I checked - yep, same size! It is sturdy enough - and large enough - that I feel very comfortable typing this into my iPad with the keyboard on my lap.

The second thing that piqued my interest is a stylus. Since I’ve not ever used one, I was very curious as to how well it might work. <Contented_Sigh/>. While I wouldn’t buy the set just for the stylus, it is a very pleasant addition to my toolkit. I am looking forward to using it with some of the drawing programs on the iPad.


Another big event (well, it’s big to me…) was the purchase of a new domain and web-hosting from Bluehost. My plan is to use the new domain as a kind of “sandbox” to play with new techniques, technologies, and designs. Hopefully, it will also be used as a development center for client projects. I was so impressed with Bluehost, I recommended them to my friends in Atlanta (for whom I volunteer technology services) as their new hosting provider. Until now, I have been “too busy” to purchase my personal hosting from them. This has been happily remedied now. Highly recommended!


Last week I mentioned how I had configured git to “auto-publish" the website I am working on. This week, I discovered a small hole in that strategy - thankfully, it was easily remedied! The "hole" appears when you wish to "stage" the site - to "test publish" the site for others to review or to test the site with other devices (iPad, iPhone). Because the changes to the git repository are "absolutely" checked out into the hosting provider’s system, you wind up "overlaying" the current production site with development changes (you are developing on a separate branch, aren’t you?). Not good! In addition, should you wish to set up a subdomain - for example, “test.example.com” for your “example.com” site - as a staging site, it becomes difficult to publish to the test site.

As I said, the remedy was relatively easy, once I did a bit more reading: use git clone to create a copy of the repository (repo) on the hosting server. In the parent directory (the directory in which I wanted my subdomain’s DocumentRoot to be), I issued the following command:

git clone -l --no-hardlinks /path/to/existing/git/repo test

In the command above, “test” is the subdirectory which is “home” for the subdomain. It MUST be empty! Since I desired a “full” copy of the repo, I choose to use the “—no-hardlinks” option. Read the docs for all the juicy details. The test/staging site is manually updated with a “git pull” as needed.

To solve the “overlaying” problem, I added the “master” branch to the “git checkout -f” in the hooks/post-receive script. (See the “auto-publish" link above.) I’m keeping my eyes open for a better way to do this.


An important milestone was reached this week: the first of the websites (for my start-up friends) to be redeveloped became structurally complete! There are, of course, a number of layout “tweaks”, typographical adjustments, and what not, but the site is viewable without “burning your eyes”. As I mentioned above, I published the site to a staging area for our team to access and review (and create the list of “things that aren’t right”). Along with that, I added Matt Kersley's Responsive-Design-Testing. This simple page includes a neat little Javascript that shows a website - on a single web page - as it will look in various smartphone browsers. If you host the page on your site, you can actually browse your site within each of the “windows”. Neat! And Highly Recommended.


Beginning to redevelop the next site gave me the opportunity to exercise what I’ve learned so far about git. I still have a few things to get comfortable with - and probably several more to learn, but, in general, setting up development was reasonably easy. The only thing I did “wrong” was copying some files via the command line before I set up the git branch I wanted to develop in. Once I figured that out, it was easy enough to move the copied files, set up the branch, and continue. Even adding in Bootstrap as a submodule was “easier” this time, though not as straight-forward as it could be. And keeping up with the “upstream” is still “interesting”. That creates a “tension-to-be-managed”, though, not a “problem-to-be-solved”.


The final thought for this week is as much a reminder for me as anything else. When redeveloping a site, it is important to get a shell for the pages established before worrying too much about anything else. My tendency is to try to redevelop the home page in its entirety first. This has turned out - twice now - to be a false start. When using a back-end framework like CodeIgniter (as I am), it seems to be more important to get the general structure - especially header/footer - established “first”. You can then concentrate on filling in the center of the page for the remaining pages.


How has your web work week been? What have you learned this week? Did you learn anything here? Let me know in the comments or via Twitter retweets!

Bootstrap.css, CodeIgniter, and MacPorts - oh my!

This has been an interesting week in JAX, development-wise.

I have been volunteering with a start-up company out of Atlanta for quite some time now.  Recently, we decided to change hosting providers (hello, Bluehost!) and, during the move, to add a couple of new domain names.  Since we are essentially moving our old content to the new domains, this would be a great time to “clean up” our websites as well.

And what a cleanup effort it is turning out to be!  One of our websites appears to have been produced with a “site-builder”.  Its structure could best be described as “archaic”, with its heavy dependence on multiple embedded tables for spacing, and images to get the look-and-feel that was desired.  Some of our other sites are based on WordPress - nothing wrong with that, really, if you are producing lots of “story oriented” content.  However, we are using it to produce basic pages, and as a result have too many custom page templates - essentially, one per page!  (Let’s be clear:  I’m not finding fault.  It is often better to have a page set up any-way-you-can than to have nothing!  It’s just time for some clean up.) 

In order to create a more modern set of sites - with less run-time and development overhead, I have chosen to use the CodeIgniter PHP framework for the back-end. (Note:  You’re going to want to have their GitHub - more on git below - link.)  The look-and-feel is based on Twitter Bootstrap with some elements of HTML5 Boilerplate added in.  As a result, IE6 will no longer be directly supported.  (IE6 users MAY choose to use the Google Chrome Plugin, if they wish, to continue to use the site(s).)

Since my background is in software development for LARGE companies, I have a growling-need-in-my-gut for source control.  There is nothing worse than cleaning up late in the day only to suddenly realize that you just deleted all the changes from the last two weeks.  With no backup.  ARGH!!  With all the HUGE changes I am attempting, I needed the comfort a source control system provides.  Recent reading and testing has convinced me that git is certainly the way to do source control today.  Indeed, if your hosting provider supports git, it is an excellent way to manage the deployment of your site(s) as well.  (You’re going to need a link to and/or an account on GitHub at some point if you work with git.  If you follow the links in this article, you’ll find many of them wind up at GitHub.)  If you are new to git version control, this article describes my general approach.

Initial setup with the new hosting provider was accomplished a couple of weeks ago.  The git-based deployment system mentioned above is so sweet!  This week, then, found me working on converting the previously WordPress-based site(s).  I first extracted the site(s) with SiteSucker as HTML.  The process of creating generic headers and footers came next.  This was aided by the “generated” nature of the WordPress sites.  While it was a lot of cut-and-paste, at least it was fairly consistent cut-and-paste.

With a basic backend structure for the pages in place, it was time to “modernize”.

My first attempt was to use Sass to “consolidate” all the CSS from the WordPress theme and our considerable customizations into one file.  (Hence, one of the things I dislike about using WordPress for “pure webpages”:  Every page not only needs custom HTML, but CSS as well!)  While I was able to consolidate the myriad of CSS files and many of the selectors contained in them, applying Bootstrap proved futile.  In the end, “redeveloping” the pages proved to be the easier.

(This is where I get to tell you that if you aren’t using LESS or Sass to “do” your CSS, you’re wasting time and energy.  If you STILL think CSS is the only way to go, don’t read this article!)

"Redeveloping" without "making the same mistakes" is a challenge - you certainly cannot do it in a hurry!  My process began with isolating generic headers and footers, and continued with specific page changes.

The footers were relatively easy.  I had done much of the work on them for one of our other sites. The headers, though, were more complicated because they are, well, complicated (they contain two navigation bars), and because I am still learning Bootstrap.  Here is where spending a little extra time really paid off.  After searching on Google for a while, I wound up back at Bootstrap's excellent documentation site.  My mindset was similar to when I first started using a Mac - I thought, “It can’t be that simple.”  A few hours and some patient thinking about the general look-and-feel later, I found that indeed it is that simple.  I even spent a little additional time and added cute icons (from Glyphicons - included in Bootstrap) to the first navigation bar.  Sweet!

In the process of working with the headers and footers, I realized I wanted to adjust the mechanism that included them into each page.  I had already decided to create “thinner” controllers than most CodeIgniter tutorials show.  In essence, my controllers are only the smallest of conduits between a model (when one is required) and views.  Views, then, become a bit “heavier”.  They are entirely responsible for how the data is presented.  For example, our views actually nest three “sub-views”.  The first level is the major content presentation.  It then includes the header and footer sub-views.  Because of the two navigation bars, the header sub-view includes them as sub-views.  Once I got my head around where to put the actual HTML tags (in which files), this was really easy.  And it afforded me the practical luxury of working on one thing at one place at one time.  Sweet!

Here is where I get to talk about another high point of the week - Bootstrap customization.  After a couple of false starts, I finally settled on including Bootstrap into my project as a git submodule.  This will allow me to update Bootstrap without the messiness of re-applying my changes.  Also, I was (after quite a bit of reading) able to use LESS (the “CSS language” Bootstrap is written in) to very simply apply the customizations our sites require.  Essentially, I created a “less” file in a folder in my project.  In that file, I used @import to bring in bootstrap.less (both the main file and its “responsive” counterpart).  Then, I added the “overrides” I desired for our sites.  To add further ease to the process, I am using the LESS.app on my Mac.  This app “watches” a set of “less” files and, when they change, automatically invokes the “lessc” compiler to produce corresponding “css” files.  Sweet!

As of this writing, the process of redeveloping pages continues.  I have hampered my own efforts, somewhat, by working on the CSS (or more properly, LESS) for pages as I encounter them.  While the result is highly satisfying - and generally helpful, since several pages “resemble each other”, I am shifting over to the mode of “getting all the pages changed”.

Distractions also “hamper” development efforts.  Being a geek, one of the happy distractions I encountered this week was an attempt to update GIMP via MacPorts.  The MacPorts team decided to update one of the components gimp is based on - webkit-gtk.  Since I prefer to NOT use X11 as much as possible, I helped discover a couple of build anomalies in webkit-gtk.  Aside from the process of waiting for HUGE builds to run, the experience of interacting with the MacPorts team was quite enjoyable.  If you are a developer, on a Mac, and don’t use MacPorts, why not?  Highly recommended.

More development is on tap for the coming week:
  • Finish the rough conversion to Bootstrap
  • Setup a “test” subdomain so that the team can “oooh and aah” over my hard work :)
  • Write another of these updates!  I forget how much fun it is to write.

On a personal note… As much fun as it is to write, it is a LOT more fun when you respond. Please consider retweeting, posting a comment, or linking back to this article.  When you DON’T do that, it is like talking to someone who never responds - no change of expression, no head nods, no questions or comments.  Actually, when I think about it, THAT’S terrifying!  So… Please… SAY SOMETHING!  Thanks.

scottmagdalein:

Google is sharing interaction numbers about Google+ instead of engagement numbers. That means they’re telling everyone about how many people are interacting with a Google+ related products rather than people that are engaging with Google+ directly.

Newsies are really upset about it, too. They…

section9:

inothernews:

This is incredible.  Please go read it.

Wow. I was not expecting that.

(via tonysteward)

Please enjoy this video of Seryn (@serynsounds, http://www.serynsound.com/).

If you are in the area, you can see them at the location below.  Highly recommended!

attpac:

See Seryn, with Bethan, at a free Patio Session on Oct. 27 @ the Winspear!

Git Is Simpler Than You Think

nfarina:

It was about one year ago that we switched to Git. Previously, we used Subversion, through the Mac app Versions, which (rightly) holds an Apple Design Award.

I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet. There was much grumbling from my teammates, who were busy enough doing actual work thank you very much.

But I pressed forward. We signed up for accounts on Github. We learned how to type 'git push' and 'git pull'. We became more confident. Git is just like any other source control system! But it wasn’t long before one of our devs called me over to look at a…situation.

Read More

Tags: Git Tutorial

bufr:

Being a programmer is hard on the body. Given, there’s not a lot of risk of slicing a finger off, or breaking a leg, but programmers don’t exactly have swimmer’s abs either. What tends to go wrong for the common fellow nerd who spends hour after hour exercising his or her brain rather than their…

This morning, I set up a new Tumblr blog to help communicate with family and friends during the miracle of the end-of-(this)-life process my father-in-law is experiencing.

Please feel free to connect with the immediate (local) family there.

The Google Docs Viewer just got a whole lot more useful. Now, it lets you view more than just PDFs, Microsoft Word and PowerPoint documents, displaying 12 new file types, launching from the Gmail application, Google Docs, or embedded in any website.