Archives for Category / Web

  • Gesture-Based CSS Selectors

    [This is a short, informal proposal of a concept, with a more extensive version in the near future. However, this should be enough for starting discussion on its value/implementation.]

    What are Gesture-Based Selectors?

    Gesture-based CSS selectors are a combination of the current set of CSS selectors/pseudo-selectors to include new set of gestures currently being used in mobile (tap, tap hold, swipe, etc.). The main goal is to give basic interactivity to elements without JavaScript support.

    The closest analog would be the same sort of relationship with CSS3/JavaScript animation. In the current methodology:

    • CSS3 – basic/simple animations, removing the need for JavaScript resources
    • JavaScript/JavaScript Library via Events – complex animations, requiring more functionality beyond CSS3 animations

    Initially, this was just focused to touch gestures. However, this can be also be extended to other "gestures" such as the current JavaScript events "click", "mouse(over/out)", "key(up/down)", etc. This will allow for non-touch gestures → keyboard, voice/speech, inputs from any other devices, etc.

    CSS/Gesture Selectors Format

    The concept is to have these represented in CSS code by the following selector (in two versions, using the mobile gestures swipe left and tap hold as examples):

    1. selector:gesture-(gesture name)

      Similar to :hover, :focus pseudo-selectors (using current

      Examples:
      div:gesture-swipeleft { CSS code }
      a:gesture-taphold { CSS code }

    2. selector[gesture=”gesture name”]

      Similar to attribute selectors, introduced in CSS 2.1 but in use more with CSS3

      Examples:
      div[gesture=”swipeleft”] { CSS code }
      a[gesture=”taphold”] { CSS code }

    Constraints/Problems

    At this point, three initial problems appear:

    1. New Devices/Platform w/ Gestures – some sort of path/procedure needed for recognization of new gestures that is open and flexible. I recommend the following for an initial path:

      Device/Platform Support → JS event support → CSS/gesture selector available

      This will allow for the availibility for selectors mention above. However, there is the problem of device-specific gestures, which could mean that certain selectors will be available for only those devices. Currently, the touch events are only available on touch enable devices. If a [front-end] developer was writing code for a non-touch enabled device, the JS support would be non-existant -> no CSS/gesture support

    2. Gesture Uniformity – if a gesture gains support across platforms/devices, the related CSS selector should never be prefixed as we currently have for CSS3 features like animations or tranforms, ie "-iphone","-android", etc. I recommend this because unlike CSS3 features, these are OS based issues ("native"). The selectors will be device/platform "neutral" – let platforms/devices be solely responsible for interpretation.
    3. Computer Processing – if this gets implemented, how does this effect processor/power usage. How does the current set of CSS3 features (transitions/animations) deal with different computer processing power (hardware accelerators?)

      If this gets added to the current set – will there be a bigger demand for hardware processing? What would this mean for small, less powerful devices? (the drive behind iPhone design and construction).

      Overall – This is an issue that will need to be taken up post-proposal, with people more knowledgeable than me.

    In summary,

    1. Creation of CSS/gesture selectors to allow for basic interactivity, without the need of JS events
    2. Providing a “path” to allow for more gestures, not just current but for future devices/platforms and be platform/device independent.

    Flickr – Scans of hand-written notes from Polaris notebook

  • What is Project Ottawa?

    a method of building a visual model of an web application UI/front-end layer

    During the past four months, I have been presenting previews of sketches and notes from my notebook via Flickr.

    Preview Sketches:

    Project Ottawa [or the Ottawa model/diagrams] started in late February, prior to my trip to Ottawa for Jonathan Snook’s SMACSS Workshop. It was there that I did the first initial sketches post-workshop and a few weeks later, created the first draft.

    After some review and criticism from a fellow co-worker, I decided to work on the second draft. This took more twice as much time as the first, with testing and constant revisions. However, at this point, I am writing the final pages and presenting the Second Draft as a microsite in early/mid July.

    The Model

    In short, the model is based on a) recent work on modularizing CSS (via Nicole Sullivan, Jonathan Snook and etc), b) analog to linear algebra, most specifically linear transforms, and c) my ideas on the UI layer, based on a concept called The Information Layer.

    With these three items, I designed a visual “code” with symbols representing blocks of programming code and content. By examining mostly my own work, I developed the rules and basics to use the symbols to represent not the parts of the web application system, but also describing interactions withing the system.

    The original purpose of this was archival, record keeping for myself. However, I began to realize that there was nothing out there that visually describes the work that FEDs [front-end developers] were doing. We have code and and can talk about CSS, HTML, etc. But, maybe for the first time, there was something that allowed the work to be visualized and be more tangible.

    Status

    Currently, this is the second draft. Even though models are always being revised and changed, I kept the term “draft” because I wanted to present the working model in a state that was good enough for demonstrations. However, this draft appears, so far, to be close to being stable. Naturally, there is more work in the near future.

    Final Preview

    As I mentioned before, the final document will be presented as a microsite around early/mid July.

    Before that, I created a single page preview, giving a brief overview of the model and its use in “mapping” a single page, AJAX driven site. This is based on the sketches/drawing from the last Flickr preview and the same example will be used as a case study in the final document/microsite.

    Final Preview – Modeling a single page, AJAX driven site

  • A Brief Musing on the Supposed Separation Between Mobile and Desktop

    A couple of months ago, I was looking at a promotional video touting some new technology. Something that was written solely for mobile. They went on about their processes, that by focusing not on the desktop, they were saving file size and increased performance, which is all and fine. Anything to life better, especially on those days when I want information without waiting for everything to compose itself during the morning rush hour. But at the end of this, I wanted to ask this question (which, in hindsight, I should have added to the comments):

    Why should there be anything difference between the desktop and mobile?

    Before answering, think about it real hard.

    Don’t worry. I’ll wait…

    The current paradigm of mobile is based on two things; the mobile phone and the tablet. But isn’t this the same sort of think we had before – the PC as the desktop. Didn’t we got over this? I got over this years ago, especially when my previous job required me to work with both Windows and Linux.

    What I am thinking is that the current paradigm is just as short-sighted.

    Let me put it this way? In a year or less, why not see a mobile device become the desktop?

    Why not give the "desktop" have touch-enable events like its mobile cousins?

    What I am imagining is the mobile/desktop schism not just disappearing. It simply gets redefined.

    If my life is nearly almost located within the confines of my mobile phone, why not go all the way?

    Our perception of the desktop is that of the monitor tethered to an external hard drive and et. al. What about a rapidly approaching near future where our version of the "desktop" is a mobile device tethered to cloud storage.

    Just a thought?

    Don’t wait too long.

  • To All My Co-Workers And Clients:

    I want to apologize for all the bad coding decisions that I have made during the last couple of years. A number of decisions were made with ignorance as the impact they may have made in terms of performance. Some of those decisions may have been made without consideration for the user.

    If I seem out of sort during the last couple of week, it was simply because the changes I need to make will require changing not just code but a mental process. Like anything, this will take more than a fortnight to change. It is a process of renewal and making mistakes and just throwing stuff into the trash bin.

    What I need is some understanding and some patience while this process works itself out.

    Sincerely,
    Ivan Wilson
    Front-End/UI Developer

  • Today, I’m Blowing Up My Code

    Seriously. http://twitter.com/#!/iwilsonjr/status/124622801914171392

    This is not a joke.

    If you are laughing at this, I understand. It still won’t change anything.

    Let me explain.

    In 2009, through contact with interaction designers, I saw the coming wave that we now call mobile. That wave moved so fast that it took everyone by surprise. Today, designers and developers are dealing with this via responsive design and other techniques.

    Now, what does it have to do with me. One day recently, I was tasked to revised some code I made in late 2009. Now, it was good by those standards but it has a few faults. Not perfect but usable and everyone was satisified.

    At the time, it was "Job done. Go to sleep."

    But I didn’t.

    (more…)