Tag Archives: Limits

Some more meanderings on Git

In my last post, The frustrations of VoiceOver, I alluded to “actively using Git/ Github in my workflow to my advantage” in the process of building a WordPress theme, bA53. And I’m still on it. But I’d very much like to flesh out a few idea’s concerning how I use Git towards my web development efforts.

What is Git? While one couldn’t be blamed for thinking I’m referring to the British noun “git” — and no, I’ve never heard of it either prior to tripping over it on Google — which apparently means an “unpleasant or contemptible person,” I’m not.

Rather Git, I’m speaking about the software now, “is a distributed revision control and source code management (SCM) system with an emphasis on speed.” I’ve mentioned my use of Git previously, as far back as my first post on this blog, in fact.

But I’ll save you from the pain of having me actually explain something I (still) barely understand, so I’ll simply recommend watching these 4 video’s that do a far better job of explaining Git than I could ever do. And it’s done. Read “Some more meanderings on Git” in its entirety

Keyboard accessibility

Not that long ago I wrote about my initial experiences with Assistive Technology. And even though those experiences happened quite some years ago and I’ve undergone a lot of healing and a number of behaviour alterations since, I still use a handful of alternative means to access a computer.

But by far the most important one I use, that makes the time I spend on a computer much more productive and enjoyable, is the manner in which I use a keyboard.

As my physical ability has progressively changed, my needs — in the sense the solutions I use — have not. Well that’s not entirely true. I no longer need switch access scanning or mouse keys, but I still heavily rely on the keyboard, and sticky keys especially, to interface a computer. I can use two hands to type, but that can be challenging (working in Photoshop is the exception) so I don’t typically use both hands. But in an effort to speed up my productivity I don’t so much require said solution, as I much prefer to use it.

Which gets to my point, my most productive use of time, in terms of my access, is the keyboard. Most of the solutions I currently use involve these 90 keys that lay before me. Read “Keyboard accessibility” in its entirety

Adaptive web design

I’ve thought, for quite sometime honestly, that most of a persons success in using technology, and the internet specifically, is directly related to both a person’s willingness and ability to adapt. And while parts of my thinking still reflect this belief, large parts of those thoughts are not so much changing (in the sense my opinion is flipping), as they are evolving.

Before I proceed I’d like to define what it is that I meant by “success in using technology” above. Just for the record, I’ve never thought a persons perceived (whether it’s an internal or external perception) failure to interact with any given piece of technology was the fault of the user. It’s not. It most definitely is the fault, or better still, a short-sightedness of the creator. Nor do I think the word “failure” is valid in this context either. Failure and it’s implications would suggest this is a black and white issue. And it’s not. Not by any stretch of the imagination. As with anything there are shades of grey. As there are varying degrees of success.

That said, I’d very much like to alter what it is that I meant when using the word “adapt.” How I was using the word wasn’t entirely fair. It placed too much of an expectation on the user. It’s not any users job to adapt to technology. It’s technology’s need to be used by us. Otherwise why was it thought of and built? I’d simply like to swap “adapt” for “learn.” Most of a persons success in using technology is directly related to both a person’s willingness and ability to learn how to use it. The trick is to make that initial learning curve as inviting as possible. Easier said than done. Read “Adaptive web design” in its entirety

Some things will never change

This is my long overdue third and final post in the series of “describing my computing career.” Please refer to The origins of interest and The gamut of ever changing ability for the first two parts in this series. However I think we need to back track a little from where we left off, especially considering certain events that I was alerted of this past week, which are largely responsible for me writing this post today.

As I’ve discussed previously (again in The gamut of ever changing ability), I started school in the fall of ’98 with the intent of pursuing a certificate in Web Publishing. But by the summer of ’99 something changed. The web no longer had the same allure as it once did for me anymore. Honestly as I was starting to consider enrolling in college I had my eye on two prizes. Web Development specifically and Digital Publishing more broadly.

There was no denying it, Photoshop had it’s claws in me. It was that summer when I began my slow transition away from the web towards a focus on digital imaging. And just prior to my graduating college, which was actually December of ’01 (I missed commencement for that year so I had to wait until the next October), I attended my first of 4 PhotoshopWorld’s in September of 2001.

It’s a damn good thing I have more to talk about today than my Photoshop work. Aside from a bunch (is that 4?) very exciting trips to Florida and the amazing experience I was able to glean from being part of the most recognized gathering of Photoshop talent in the world (that may not be true, but it sounds great), keeping busy with Photoshop, at least, proved very tricky. I couldn’t find a market for what I spent a good 4, probably more like 7, years learning and doing. Fortunately I kept my other eye on the web. And my feet just barely wet enough to return to it should I ever wish (read: need) to. Read “Some things will never change” in its entirety

CSS resets rediscovered

It was back in January of this year that the idea for FSSFive — a WordPress theme built on/with Fluid Skinning System (FSS) as a foundation to allow components of Fluid’s Infusion to make the most popular blogging platform on the internet (more) accessible — was born. Or that was the goal. The jury is still out on my effort, which isn’t by any means complete. It was then attitudes concerning deeply engrained personal habits started to be scrutinized. Namely the use of Cascading Style Sheet (CSS) browser resets in my design process.

Essentially all CSS browser resets are, is a bunch of lines of computer code usually inserted at the beginning of the file that handles a webpage’s (or more commonly a website’s) presentation information. And it’s these rules, if you will, that serve to put different web browsers at an equalled point where a designer can start designing from. Because every web browser handles their default inheritance, sizing and spacing issues a bit differently. And it’s this useful technique that puts everything “back” in it’s place. In a consistent manner. Across web browsers.

But as I started to develop FSSFive my thinking began to change. For years I become quite comfortable, meaning I no longer thought at any length about this issue, and used the popular Meyer Reset. Which isn’t a bad thing (this isn’t a criticism of Eric’s “tool,” in fact it is praise, it served me remarkably well for over 5 years!). I just threw it in at the start of any project, as a first step, and “designed” from there without a second thought. Read “CSS resets rediscovered” in its entirety