Archive for the ‘New’ Category

Pebble Time Review

Sunday, November 15th, 2015

Since my last Casio calculator watch broke a couple years ago, I haven’t been wearing a watch. This August, I ordered the red Pebble Time. I’ve spent a while looking at different smart watches, and practically all of them fell short. Anything that required a back-light couldn’t show the time unless you made some kind of gesture, and the battery life on most of them are terrible. The first Pebble watch couldn’t even display colours.

Initial impressions are good. The colour is stylish, though it can clash with my outfits if I’m not careful. I was afraid it’d turn out to be thicker, but it’s actually a really good size. The bezel is too big, but what can you do.
The metal pieces are really nice. They seem to be some kind of anodized aluminum. The face bezel will end up scuffed very quickly, so if that bothers you you’ll need to reconsider or apply some kind of protection.
The silicone band feels great and hasn’t caused any problems, yet. It’s a standard buckle strap, and it’s got a couple of those loop things to hold any excess strap down, but I find they add too much thickness. I’ve got four layers of silicone from the inside of the loop, through the overlapping strap, to the outside of the loop. Despite that, it hasn’t usually been a noticeable burden. There have been a couple times where I’ve been typing or writing and the loops got greasy and slid around the band. It’s easy to clean, at least.

One of the things I was looking for was a watch that would show seconds. I managed to find a black-and-white watchface that did what I wanted. Luckily, It’s fairly easy to code your own faces. They’ve got a cloud-based IDE with a built-in emulator, and running it locally is as easy as plugging your phone into your computer and turning on the developer option in the Pebble app. (I tried running it in Chrome on my phone, but it got confused and didn’t know how to connect.) Everything is pushed to the Pebble watch from your phone across the Bluetooth connection.

The display looks great. It’s relatively pixelated, though, at 144 x 168 (176 ppi). Normally I’d complain that it’s smaller than a Super Nintendo video feed and that you can’t watch videos on it, but these days we’ve all got phones for that. The screen is a bit tight for certain types of information, like barcodes, but it’s possible to put some in.
While the colours themselves are good, the backlight is horrible. If this were a watch that needed the backlight to function, it would have ruined the experience for me. As it is, I’ve all but disabled the backlight and just turn it on when I need it. The glass has an anti-reflective coating on it, so I can read it even by the light of streetlamps. The screen itself isn’t optically bonded, so there’s another layer or two of reflections that sometimes do get in the way. Luckily, brighter environments tend to also show the screen better, so I haven’t run into too many problems with reflections obscuring the time.

The animations and use of colour in the operating system look great. I get notifications for texts before my phone buzzes. I’ve also never missed a call since getting it, even though I usually fail to notice the phone vibrate in my pants or I left the phone in another room.
I’ve managed to get an entire week on one charge, so it’s definitely long-lasting. You won’t have to worry about making it through the day. Apparently some people can’t even get a week out of it, so I don’t think updating the screen every second drains the battery as much as I’d feared it would.

Overall, I find the Pebble Time both useful and stylish. I’m having trouble reconciling the USD$200 I spent on it, though. I’ll probably be able to extract all that value out by coding my own watchfaces and apps, but most people might be too limited by what’s available for the purchase to make much sense. Still, your options are slim: if you want an always-on, transflective, connected device, you can get a Pebble or you can pay far less for something that displays only the time and date and little else.

If the colours and style don’t matter to you, compare its price to that of the original Pebble. It’s a good device on the whole, but it does have some limitations that pop out from time to time.

Writing in the Browser

Thursday, November 24th, 2011

As a writer, I’ve tried a few different formats. I think it occurred to me, one day, that newer formats won’t work on older systems, and old formats could lose data in the future when programs try converting them to newer formats.

I’ve been writing in plaintext files, which is of course human-readable. The only problem I had is that I can’t italicize or bold, and other formatting options were severely limited.

I tried RTF, but a look at the source made me cringe. It wasn’t even as if they added codes where the formatting was; it was more like every second word was just a slurge of backslashes and random characters. It was not human-readable.

So what’s human-readable and still rich-text? I had the idea to do something with HTML. I created a simple document with a contenteditable attribute set to “true”. I also did a trick to make the style element visible by setting both head and style to display:block.
I was left with a page that I could alter at will, using such built-in short-cuts as bolding and italicization. If you look at the source, there are <b> and <i> elements around certain bits of text in <p> elements, all completely human-readable. I can just save the page back to my drive.

<html contenteditable="true"> <head> <style id="bookStyle"> * {font-size: 30pt;} </style> <style style="display:none;"> head, style, title{ padding:14px; display:block; font-size:14px;} </style> <title>Editable Page</title> </head>
<body> <p>Text here...</p> </body> </html>

I also made an external css sheet specifically for writing books, which I @imported in by throwing it into that editable style tag, and I made some convenience JavaScript which I insert by dynamically creating a script node at the end of my body and inserting it into my head.
I’ll go on about that script some other day, but it basically gives me keyboard shortcuts to insert things like em dashes and horizontal rules, and asks me if I really want to leave if I have unsaved changes.

If I press Ctrl+S, it removes the external script from the document before saving. This way, there’s no whateverpage_files directory taking up space and causing my page to constantly point to an old JS file.

It’s pretty nice! I can easily change the size of the text or the typeface to suit my mood, and there isn’t too much clutter in my actual file. I’ve got my stories in a format that will most likely last longer than any other. It’s kept in an XML format, which means I could very easily make an ePub book out of this when I finish it.
Or I could use some sort of XSL transformation script to output ePub as I’m writing it, if I want to share.

Object Oriented Programming in JavaScript

Tuesday, December 14th, 2010

(From A Student View)

When an institute is teaching programming to new students, it’s a common theme to play around with Java before going on to other languages. It’s easy to learn, has all the Object-Oriented goodies instructors want, and is fairly ubiquitous.

With the current snafu that is Oracle circling around Java and all the rest of Sun’s old open-source projects, I decided I would try my hand at emulating those same principles using JavaScript; an open, simple, ubiquitous technology.

As it turns out, the resemblances end with those adjectives. JavaScript was never really meant to do the things we’re making it do now. It’s possible to do most things in most languages, but the verbosity of the code needed to perform a specific action tells you what it’s made to do, and what’s been tacked on as an after-thought.

So, from a student’s point of view, how does it matter which language they’re using? Which is easier to learn, or simpler?

Java:

  • Requires each class to be in its own file. It can be tedious, but it can also make it easier to manage.
  • Each file has one class. Each class has a constructor (sometimes overloaded), and zero or more methods. The structure is fairly simple.
  • Besides the keywords, not much is being used. If you don’t import anything, there are very few class names already taken.
  • It’s made to work with the console, or to display a GUI.
  • Inheritance is an important part of Java, and all you need is one keyword and the class name to inherit.

JavaScript:

  • Everything can go everywhere, and the syntax can go different ways. This freedom can be devastating to those who are learning.
  • Objects are functions, and functions can go within functions, and what are closures, anyway? Where and how you create variables influence how you can access that variable later in the program (private, public, hidden, privileged, for either fields or functions).
  • The global scope is chock full of different classes and attributes and functions.
  • It’s not meant to do anything on its own. You have to teach students HTML and DOM manipulation at the same time, and programs have to output in HTML.
  • Inheritance is handled through the prototype chain, which has to be explicitly set after an object function is created. You have to set the prototype of that class to a new instance of the parent class, and then you have to set that prototype’s constructor back to the constructor of the current class (to ward off some edge cases).

I’ve made a sort of console window out of HTML. It overwrites the document.write(), prompt(), and confirm() methods to output to a <pre> element. The latter two also pause execution by opening an invisible modal dialogue that is closed when the Enter key is pressed, which enables synchronous user input.

It’s a cludge, but you can run any JS code in there that acts like a console Java program.

Later: GUIs.

In short, You can do Object-Oriented programming in JavaScript, but it’s not something you should be teaching students in their first semesters, and the complexity and power of it don’t lend well to simple instruction.

I’m going to keep playing around with this, to see if I can get something simpler out of it. I just got the ‘instanceof’ keyword working, so I can start chipping away at what I need to get a ‘true’ out of that.

Edit Style

Tuesday, October 5th, 2010

I just created a bookmarklet! Try dragging Edit Styles to your bookmark bar.

This only seems to work in Chrome, Safari, and IE9. If anyone can tell me why appending an element to the DOM in Firefox or Opera creates a blank document, I’d love to know.

You can type any sort of CSS in the box. If there was already some CSS in a <style> element in the head, you can edit that.
Try something like the following:

Drop-Caps

Friday, August 6th, 2010

WHAT DOES IT MEAN???

This is a Daily Drop Cap from Jessica Hische. I encourage you to take a look at her typographical wonders.

XHTML vs HTML

Tuesday, July 6th, 2010

XHTML is barely more than a clone of HTML written in XML. To put it in other words, XHTML is the XML serialization of HTML. There should be no differences in the Document Object Model between two documents written respectively in HTML and XHTML, if both are well-written. There are several polyglot issues, such as XML namespaces, which HTML5 allows for the sake of intercompatibility between the two serializations.

What are the differences, then? What should you use?
As with most things, it depends entirely on your circumstances and goals. I’m a programmer, so cleanliness and predictability is more important than ease-of-writing. When you mark your pages up in XML, you gain certain benefits: the ability to add MathML, SVG, RDF, and other XML technologies (though MathML and SVG are included in HTML5); the ability to use XSL transformations; and the ability to read your files into the browser with JavaScript to parse and display certain pieces.
When writing in plain HTML the browser is watching over you, and your code will work even if something is a bit wrong. You rarely need to test, and can throw whatever garbage you want into your page. In short, you can do the kind of stuff that gives programmers nightmares (and also funds quite a bit of their work).

So that’s where it is. People with no experience can still create content for the web, while anyone who wants to say they know how to code (even if they only code markup, rather than program) must adopt proper coding standards.

Essentially, XHTML is HTML. If a ‘programmer’ is learning HTML, the X can be assumed. There is no reason to even mention XHTML anymore, because (beyond a few quibbles) the markup a programmer writes and the markup someone else writes should build the same DOM.
They are learning to mark up hypertext. The serialization is only a detail, for advanced usage. Even the new doctype is the same for both HTML5 and the XHTML serialization of HTML5. (I’d say XHTML5; but that’s a misnomer, as it is actually XHTML 1.0.)

Now, the argument between text/html and application/text+xhtml is another story (and is XHTML 1.1 rather than 1.0), and one that I should delve deeper into in a later post. But as far as naming goes, for standard code being served to a browser with no special headers being changed, the X in XHTML is little more than a name.

On Curation

Tuesday, June 22nd, 2010

As website owners and content creators, we have a duty toward the users of our content. When we blog about something, the information we throw to the world could very well become dated and wrong.

What Can We Do?

When you write about a modern topic, that post is almost guaranteed to become stale and useless, if it sits the way it is. As such, there are a few things you might do:

  • Keep a clear separation between posts you’re willing to curate, and those that are simply snapshots of life (real blog posts)
  • Set a kill-time for each (curated) post when you create it; after which it is no longer viewable by the public, and becomes hidden until you can revisit it and freshen it up
  • Allow errata to be submitted to curated pieces, so that readers can help you improve the article
  • Keep a list of the curated pieces, possibly by listing links to those pieces on a separate page

I’m thinking of doing the above with this blog. Some of the posts I’ve written won’t be useful in the near future, and others should be upkept so they always provide correct information. Perhaps I’ll implement these steps in the next iteration of my design.

The Awesome Foundation

Friday, June 18th, 2010

I’ve started the wheels turning on this, so it’s time I talked here at length about my ideas.

The Awesome Foundation is an organization founded in Boston in 2009 to make things awesome. The idea is simple and powerful: Ten people come together, each donates $100/month, and the resulting $1000 grant goes to whichever applicant was judged to have the most awesome project.

To date, there have been grants given for microbial laser tractor-beams, a materials petting-zoo, bio-inks, peer-to-peer cellphone networks, grassroots mapping, and more, from chapters created in San Francisco, Providence, New York City, Boston, Ottawa, and London.

Now: I want to create one in Winnipeg. I’ve notified the Foundation, I’ve created a Twitter account, I’ve talked to the local creatives, and I’m writing this here. Things are falling into place, and I hope we’ll be able to give our first grant within the next two months.
There’s lots to do!

Pixies per Inch

Monday, June 7th, 2010

Since the Apple event, everyone has been going mad over resolutions. The main difficulty, as far as I can tell, is that the subject has never been broached, and so people haven’t been told what to think.
“I’ve been using 100 dpi (or less) for ever years, and it’s suited me fine,” they say.

So, what is the resolution of the human eye? It’s hotly contested, of course, and there doesn’t appear to be a standard way of measuring. In general, though, you would measure a line pair to find the distance or the print size at which those lines blend together.
A quick test on my 100dpi monitor puts it at about three feet, for me. Other research has shown various measurements, such as about 125 line-pairs per inch at about foot. The important thing to realize is that those are line-pairs, not rows of pixels. You would need two pixels to render parallel lines, so the resolution is more like 250 dpi. This is the realm where the average human eye starts having problems, but there are, of course, many different edge cases where people could see individual pixels even at this resolution and this distance. 300 dpi has been accepted in popular belief as the general limit of human eye-graininess. If you want high fidelity, of course, 600 dpi is good. If someone were examining a material at close range, 1200 is better, though 2400 is probably what you’d want for anything of truly high quality.

So, as far as monitors go, 200 dpi is just fine at a length of two or three feet. Once you get one foot away or closer, as mobile devices usually are held, you’ll want something higher; at 400-600 dpi.

If you got a huge 1920×1200 display at only 200 pixels per inch, it would measure 2,264 pixels diagonally, which works out to 11.32″. At 224 pixels per inch, you could fit that into a netbook.

Of course, such technology could be prohibitively expensive, so we’re likely to stick with increasing the density of smaller mobile screens, for now. Besides; I don’t believe we have the infrastructure to be shuttling movies around in quad-HD.

Communication Design

Wednesday, June 2nd, 2010

I was reading something Dave Seah wrote (davidseah.com; you may want to subscribe to him), and that got me thinking about basic things and definitions.

We’re all familiar with copywriters and editors. But what are they, really? In general, copy is text, though it’s usually used in a promotional manner. ‘Editing’ has a better description:

Editing is the process of selecting and preparing language, images, sound, video, or film through processes of correction, condensation, organization, and other modifications in various media.
A person who edits is called an editor.

Let’s boil that down:

Editing is the process of designing communication.

When you edit something, you’re designing it to fit objectives and requirements. What do you edit? Language, images, sound, video, or film? That’s all communication. As Wikipedia puts it:

Communication is a process of transferring information from one entity to another. Communication processes are sign-mediated interactions between at least two agents which share a repertoire of signs and semiotic rules. Communication is commonly defined as “the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs”.

There are things we share with each-other: memes, shapes, sights, smells; other sensory stimuli. These can be wrapped as a whole and called ‘signs’. Some, like language, are incredibly rich and complex, while others are base and are shared by most humans. Some people have no access to certain signs.

A communication designer takes a message and designs it—readies it for a large, diverse audience and makes the message clear and understandable by encoding it with a variety of shared signs.