Posts Tagged conventions

Posted on Programming

An image splits; time lacks distinctinction

A man named Shaun E. Kiernan asks if I know of any programs purposed toward splitting PNG files. Barring image editors, I do not.

Saying no to people is not something I do well. I offer to make him one. Development time should be brief.

I do so. It is so.

I rebel against the common over-use of text fields. I do not worry about certain conditions. If an image cannot be evenly divided, it will try for pixel fractions. This is an obvious mistake, but the fault is theirs.

I implement tarring, for increased ease-of-use. I commandeer and massage code from Bradicon. It is done in under an hour.

He laments its interface, though it seems functional. He claims it suits his need.

I spend some more time on the user interface. This is as far as I see it going.

It is a program that splits an image, and split images is what it does.

 

Posted on Business

When Google is not available, I ask Karl

I don’t know if you’ve ever used a web browser before, but a common UI convention is to display a box at the top of the window, into which you type an address (or, URL). It lets the browser know what you want to retrieve, and soon you are browsing away like a professional.

With certain websites, Chrome asks if I’d like to preform a website-specific search using a query typed directly into his very own address bar — something I find very cool and also reasonably useful.

Firefox, too, but who cares about him?
(more…)

Posted on Uncategorised

Sometimes people do interesting things!

Facebook. The other day, Jeff and I noticed their footer bar – let’s call it the presence bar, since that is how they’ve identified the div – behaves differently with different browsers!

In Safari, Opera, and Chrome it works normally. You click a link, the page reloads, and the presence bar opens to where you’d left it.

In IE (6 and 7), as well as in Firefox, not so much. The links only alter the part of the URL succeeding the hash mark. The page never reloads.
New content is loaded via an invisible iframe. On completion, the data is extracted from the iframe and inserted into the main section of the page – which doesn’t include the presence bar.

Facebook can use JS to read the section of the URL after the # and load the appropriate page, which allows pasted URLs and bookmarks to work, as well as the back and forward buttons.
If you inspect their HTML, you will notice that the links’ destinations are identical for either set. They probably use Javascript to hijack clicks via eventlisteners.

I have no idea why they’ve decided facebook should behave differently based on browser. Maybe they ran into some sort of problem? Ideas?

I prefer the first approach, but they could have done much worse with the second. They’ve made sure it preserves usage assumptions common to web applications, and degrades gracefully.

 

Posted on Business

consistency in branding

As you probably know, I designed the logo for Aquaflora Nurseries. In many ways, it has changed a lot from my original submission. Aquaflora very much wanted to use Arial Rounded MT Bold in their logo, which was not at all the fontograph I’d chosen. I switched it to VAG Rounded Std, and no one ever has to know.

Turns out they liked the change anyway, so that was a bonus.
(more…)

Posted on Programming

Magically managing menus

Hey, so, I’m going to detail my method for making menus. I’ll try as well to explain the reasons behind the choices I make. If you have any questions, let me know and I’ll try to fabricate a plausible answer.

Two popular menu types are drop down menus, and your basic expanding lists. But good news, the HTML we use for both is the same! Why? Because they’re both menus! They may look different, but in essence they’re nothing but a nested list of links. And in my opinion, we should do our best to use HTML to describe the data we’re presenting.

One big bonus is that if we take out the CSS, the website still usable. We can also easily provide alternate stylesheets for things like mobile phones, and pages are easy to navigate from text-based browsers. Most importantly, the HTML is short, clear, and easily readable.

Which is why I’m going to use nested lists. The styling will be done with CSS, and some event handling with Javascript (I’ll use JQuery because it’s nice, but don’t feel tied to it).

I’ve prepared a page complete with code quotes and comments:

I was too lazy to style it. Also, the magic was a trick. There was no magic. I’m sorry.

Your friend,
Brad

 

Posted on Uncategorised

Themes and Skins

When planning the system that I am currently working on, I had two main goals. The latter being that I wanted to be able to easily and profoundly change the way it was displayed. The former is unrelated to this blok.

To do this, I made use of a combination of themes and skins, although these are probably poorly chosen names (it was late).

A Theme defines the HTML used. It can also include it’s own CSS files and images as appropriate. Basically, you can do everything that you can do with a skin with themes. A theme has several required files, and a few special files, but can can contain anything in addition to those.
The special files in a theme are files that override the default HTML that a module uses. They take the form of [module_name]-[file_name]. For example, to override the file product.html in the products module, you need only add a file named products-product.html to your theme directory.

A skin is basically the CSS that is automagically included in theme. They also have required files, special files, and can contain additional files. The required files are ones like style.css (the main style sheet for the skin) and screenshot.jpg (which is displayed to help the user pick a skin).
Special skin files are browser specific CSS files, files that will be included with conditional comments if they exist, and files that will be included by PHP according to the browser data apache gives it. This is to allow skins to work in most browsers with some level of ease.
The skin directory is a good place to include an images directory (as css files reference images relative to their location).

Both themes and skins make use of data holders. Data holders are character sequences that mark where in the HTML or CSS file data should be inserted. They take the form: <!–#data_name–>.

So, that was my method for allowing me to easily change the way the data is displayed. It seems to work pretty well so far, but I have only made one theme and one skin as yet :P.

 

Posted on Uncategorised

appearance and conventions

I don’t like HTML in PHP. Or, worse yet, PHP in HTML. Now, obviously this is a matter of preference and there are benefits and difficulties that accompany each method.

Adding PHP to HTML is quick and easy. The main problems being that it can then be difficult to find your PHP in the mess of HTML, especially if your HTML isn’t clean — and that the idea of trying to implement a system of any complexity in this manner disgusts me. Maybe not a problem for you, but certainly one that prevents me from using this method as much as possible.

Adding HTML to PHP is the middle ground. It is easy, and good for initial testing as you only have to edit the one file that contains both the PHP and the HTML it outputs. But, again, it is not a method that I would choose for a final product, although it is a method that I would use under the right constraints. The problem with this method is that anyone who wishes to change the way the output is formatted will have to edit the PHP file itself. This is less of a problem if it is you who is editing it than if it is someone who is unfamiliar with the system, but still there is the possibility that even a simple change in formatting can temporarily break everything – typos are more common than a cold. This is also less of a problem if the HTML you use to format your output is nice, and can be styled with an included CSS file.

Preferably, interface and function would be kept entirely separate – or at least as much so as possible. Of course, doing that in a way that is both general and flexible is understandably more difficult. Separating interface and function allows for easy switching of themes and skins (that can be very different, visually) and, at least to me, is more elegant. (By which I mean, it doesn’t make me feel sick)

My next blog should explain the method I used to allow for this in the project I am currently working on.