We were talking about form design at the accessibility meeting at the Cleveland Sight Center this morning, and one of the regular Web Dev SIG attendees made a comment about how it depends on the age of designer as to whether labels or notes were put before or after an input field. Of course, I had to chime in "Oh come on now! Not all of us whippersnappers are bad form devs!" The original comment really irked me, inspiring this soapbox post.

If you are using the age of the developer or designer as a metric for web design, you're doing something wrong.

Maybe there's that stereotype that young developers will focus on new technologies as being the best way no matter what. Maybe there's a stereotype that boring HTML pages were written by older developers. And if those stereotypes are there, I'm calling you out now.

Plain and simple - poor web development doesn't discriminate. You can be of any gender, any race, any creed, any age... it doesn't matter who you are. The only way a developer can get away from poor design/development is by hearing that their design doesn't work because of {insert reason here} and then receiving constructive feedback on how to improve their design.

This isn't the first time that I've heard someone make a general remark about how the "younger" generation doesn't know how to design web forms. But I'm tired of hearing that. People enter the web development arena at various ages, and honestly, age should not even be considered when looking at a poorly written app. Prior experience, possibly... but age, no....

Labels: ageism, web development

Yesterday, I spoke at the vendor-agnostic Web Development SIG. They've started the Google Chronicles series by covering four Google products:

• Google Analytics/Urchin


• Google Chrome


• Google Calendar


• Google Maps

You can see my slides here:


I'd encourage you to download the presentation though and check out the speaker notes for more information on the screenshots.

Google Analytics and Chrome

I walked the group through getting started with setting up an account for Google Analytics and getting the tracking code on their sites. You'll notice that my screenshots show 0 data -- this is intentional. When Stuart had asked me to speak at the SIG on these topics, I figured I'd add the Analytics code to Cleveland Tech Events specifically for this. He has also scheduled a full meeting in December on web site statistics packages and how we can benefit from them. So if you're curious about my traffic on Cleveland Tech Events, come on out to the December Web Dev SIG meeting to get an in-depth view of the statistics.

I was also asked to cover Google Chrome, from a web developer's perspective. I have to admit - the more I looked into Chrome for this presentation, the more I was excited about it. I remember that when it was launched, there was quite a bit of negative feedback. It wasn't until I saw one of my co-workers with it on his desktop that I started considering it. Now, it's one of the many browsers that I test for my websites. Everything in my slides on Google Chrome comes with the default installation - I did not have anything extra installed for those features to work. The Web Inspector, Resource Tracker, Script Debugger, and Task Manager are all part of the Google Chrome base. (And yes, I did change my default search engine in Chrome to bing, and I did get a little teasing for it. It just goes to show that you can set your default search engine in Chrome to your choice of search engine - Google, Yahoo, bing, Dogpile, Metacrawler, or {insert your favorite search engine I didn't list here}.)

Google Calendar

After my talks, Bill Cohen-Kiraly talked to us about Google Calendar. He walked us through the example of setting up a calendar for the Solon band and orchestra practices. He had one calendar for each group, and he showed us how to embed a calendar on our own sites with multiple calendars showing on one calendar. He showed how simple it was to add an appointment to the calendar and how it immediately shows up on the site.

I love Google Calendar! I use Google Calendar for Cleveland Tech Events and even have a calendar for my own personal tracking. My husband and I share the personal calendar, making it easier for him to see when I have presentations and trips scheduled and making it easier for us to make plans with friends and family by checking one calendar rather than having to carry around a paper calendar or maintaining individual calendars. And yes, for those who are curious, I am using Joomla extensions that tie to the Google Calendar for my "Upcoming Events" on Cleveland Tech Events. If you have a Joomla site and need help adding a Google calendar to it, I can help with that!

Google Maps

Finally, Stuart ended the meeting by covering Google Maps. He showed us how to use their Link feature to embed the maps on our sites. Then, he showed us how he customized the maps for Notre Dame College.

For those who are interested, there is a Google Maps mobile app available, if you want to access their maps from your mobile device.

Code Playground

The last thing Stuart showed us was the Code Playground. If you want to work with any of the Google APIs, this is the interactive area to see how it works and tweak the code to your liking.

Conclusion

Being International Talk Like a Pirate Day, we told our hecklers at the beginning that if they heckled, they'd have to walk the plank at the end. Oddly enough, no one had to walk the plank. However, there were some questions and feedback. I really enjoyed meeting them, and I look forward to attending their upcoming meetings.

The upcoming meetings for the Web Development SIG include:

• October: Color Theory


• November: Accessibility


• December: Web Analytics


• January: Google Chronicles

For more details on the Web Dev SIG, check out their website at: http://www.websigcleveland.org/.

Labels: Google Analytics, Google Calendar, Google Chrome, Google Chronicles, Google Maps, Web Dev SIG, web development

Seeing this message on the UGSS site when I opened Safari for Windows instigated this post: You need IE (6.0 or higher) or FireFox (1.5 or higher) to view this site.


You've read about how disgusted I get with the whole "IE Only" crutch. Now I need to extend that call even further - developing for particular browsers limits your audience and can leave a bad taste for a potential customer. Are web developers still doing this? If so, why?


Now my guess with the UGSS site is that it's older - as those are dated browser versions. So maybe it's an old app that could use some updating? Most likely.

Yes, as web developers, we should consider our target audience. But unless your site was truly focused on a niche market, is there a reason why you'd want to develop new sites for one specific browser? If we're Apple, for example, we'll want to target our Mac fans, but at the same time, we need to acknowledge that there are other people who may be interested in our products/services who may be running one of the other popular browsers and not just the one we've been developing for.


For those of you working on the Toughest Developer Puzzle Ever, there have been complaints about one of the levels not working in a certain browser. If you let me know which operating system you are running and version of your browser, that would help me figure out where the bug is. I've tested the code in Google Chrome, Safari for Windows, and Internet Explorer 7 and 8. (Firefox and Opera were accidentally left off when I recently redid my laptop, so they were missed.) I don't own a Mac, so I rely on Mac users to give constructive feedback. From what I've heard so far, the problem seems to be with Firefox (at least versions 3.0.11 and higher) on Windows XP, which I can test when I'm near an XP machine. If you are one of those people having a hard time with stage 15 and Javascript errors (and *only* JS errors), please let me know which OS/browser so that I can troubleshoot it and possibly fix it. As you will come to learn, I am not one of those web developers who will force you to use a particular browser.


Now understand something - this call goes to all web devs out there, and not just the Windows-based ones. So Linux-based web devs who design their sites for Firefox only - this applies to you guys too. And anyone else out there who's doing web dev with just a one browser mentality - it's time to expand your horizons and acknowledge other browsers out there. You don't have to like them - but at least consider that it's more than just an IE/Firefox/Safari world.

Labels: cross-browser, web development

Many years ago, I remember seeing "Optimized for IE", "Best viewed in
Internet Explorer", and "IE Only" on websites. Nowadays, I'm not seeing
that as much, and I'm glad.

I never realized how much "IE Only" impacted me until I was helping a
friend with a project and found that the app worked fine in other browsers
for the most part, with probably just a little tinkering in the browsers
to get them to work. When I was told that the app was supposed to be "IE
Only", that caused me to get quite disgusted, and I hadn't actually
expected that kind of reaction out of myself.

Back in the day, certain things only worked in certain browsers.
Nowadays, though, browsers are getting a bit closer to implementing the
same "standards". With them getting this much closer, "IE Only" seems
more of a crutch to me, one that web developers should really get away
from.

What "IE Only" Means to Me

When I hear or see "IE Only", I see a few things:

• I'm an old school dev that knows the IE hacks and refuses to learn the
  new code that works on most browsers.


• I'm in a hurry (or maybe just lazy), and my website generation tools
  are optimized for IE.


• I don't have time to test other browsers.


• I don't care about the other browsers.


• I don't know where I can learn more about technologies that would work in more than just IE.

"IE Only" seems to be more of an excuse to get out of writing the code the
right away.

But why the IE hate?

As a web developer, it isn't my job to force my end user to lock into a
browser. That means that just because {insert browser name here} is my
favorite browser, I can't develop strictly for it and tell everyone else
that they have to use it. It's my responsibility to work with technology
that will get the information out to as much of my audience as possible.

It isn't that I hate IE - I use Internet Explorer as my primary browser on
at least one of my machines. It's that I'm tired of seeing developers
taking the easy way out. Although it might take a little time to learn
the code that works cross-browser, that time spent means that you'll be
able to disseminate your information to a broader audience.

In my friend's case, the "IE Only" claim translated into not fully
understanding how browsers handle the technology. Unfortunately, I had
run into similar issues, but I had done the research to a point to know
how to massage the other browsers to get them to work.

But I want to use technology that will only work in {insert browser name here}.

Then that's your choice to use that technology. However, keep in mind
that a lot of technology nowadays is being developed to run on multiple
browsers and platforms. For example, Silverlight and Flash both have
plugins that work in an assortment of browsers and operating systems. By
choosing an obscure format that limits itself to one particular browser,
you're limiting your end users and narrowing your audience.

My Challenge to Other Web Developers

I'm going to issue a challenge to my fellow web developers. If you're
working on new apps that are "IE Only", ask yourself "Why?" Why is the
app designated as such? What browsers are its users most likely going to
use? If IE is not the sole answer, then maybe take a look at updating the
code to be a bit more inclusive of other browsers.

Get rid of the "IE Only" crutch and become a stronger web developer!

Labels: web development