The Wilson Project Blog of UX/Front-End Developer Ivan Wilson

Menu Skip to Navigation

Tag Archive / ui

  • 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

  • Why Is Project Ottawa Important?

    We [FEDs*] have tools for building,
    We just don’t have tools for describing what we build.

    FEDs* build things – things called web applications. We use code, graphics, etc. We have tools at our disposal to do this. But there is one problem. Architects and engineers can create blueprints and models to display their project.

    We don’t.

    We have have code and content. But all of this is just words without context. And unless your are willing to search and dig through all the code and comments, its still pretty useless.

    What I did with Project Ottawa was take the patterns of building – views, code blocks, scripts – and create visual symbols with reference to these items. Here, the advantage of Ottawa is giving a visual description of the web application. Not just its parts but also its interactions and their relationships among the various parts. Its not a comprehensive view, it just has to be as concise as possible without losing too much precision. And the possibility of manipulating this data to do more interesting things in the future.

    * FEDs – Front-End Developers

  • 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

  • First Preview of The Information Layer

    First notes from my Moleskin notebook (Project Charles – Volume 1), 5/10/2009 entry

    Notebook (Volume #1 - Project Charles) - First Set

    Notebook (Volume #1 - Project Charles) - Second Set

    First sketch of new information model (same date)

    Sketch (5/10/2009) - New Information Model

    New information model (current view, comparing with previous model) – Basis for “The Information Layer” essay

    New Information Model - Current Realisation

  • Call Me Regent (or What’s In A Name?)

    Next week, I am going to move this site to Linux server.

    Not a hard process – its just a little more complex in my case since it will involve domain(s) names, file transfers, and dealing with Linux/Window server (well if you dealt with both you know what I mean). But since I am here and I made an important decisions two weeks ago, I might as well talk about it.

    The “it” being…what’s up with the name “Charles”?

    The Wilson Project/Site Versions

    The name Charles refers to Charles Darwin, whose bicentennial was in 2009, the same year the project started in March. It also added some inspiration because of the introduction of new ideas and concepts that slowly gestated and altered during the course of the project.

    But the best thing about working on these projects is that it is sort of like my own research lab. It is where I get to try out new ideas before doing in the real world.

    One part research scientist, one part Olympic athlete.

    As for this version, I decided two weeks ago to name this version “Regent” because of its transitory nature. Unlike “H3”, it was never meant to be a final version and was always going to be more of a functional placeholder for the upcoming Charles.

    And there it is.