Quicksearch
Interesting Sites
Archives
Categories
Syndicate This Blog
Creative Commons
Adobe AIR 2.0
As I was redesigning the interface to my "RefStat" (Reference Statistics Tracking) application, I came across a web page that claimed support for CSS3 in Adobe AIR, so immediately began creating the new interface using Safari 4 as a testing ground for my UI. After almost completing it, it was brought to my attention that this would not be available until version 2 of AIR was released. I am still using v1.5.x. Not awesome.
The good news however, is that there is a public release of AIR 2.0 Beta 2 for download, which gives me hope that the stable release is not too far away. Since I am also waiting on an update to the tooltip library I am using, this wait hopefully won't be too long after I am ready for it.
New features in Adobe AIR 2.0 that I am looking forward to:
Features planned for my redesigned UI (v2):
I might add a graph rendering to display current stats for the day too as I've been asked for it, but it wasn't meant to view reports, only create the data used for them. This seems less important to me than the user interface and code updates though (template/skinning was so users could switch between horizontal and vertical displays depending on their desktop icon arrangements or resolution).
Current mockup (without tooltip) rendered by Safari 4.0.5 for Windows.

I never claimed to be a UI designer.
The handles on the left/right sides are "grip" or handle areas in order to move the application. The resize/change template button is not yet implemented in this template (though all controls would be in the orange group). The notepad is the new feedback button (in place of the "T|" from before), and of course minimize and close. The image shows a hover state, not a mouse-down state. The colors are meant to be similar to our library's "official" color (#621E27 or close variations).
The good news however, is that there is a public release of AIR 2.0 Beta 2 for download, which gives me hope that the stable release is not too far away. Since I am also waiting on an update to the tooltip library I am using, this wait hopefully won't be too long after I am ready for it.
New features in Adobe AIR 2.0 that I am looking forward to:
- UDP packet support (interfacing with some game servers)
- TCP/open socket listening (acts as server)
- ~30% more efficient than AIR 1.x
- WebKit version updated to Safari 4.0.3 equivalent
- (Better?) Printer support
Features planned for my redesigned UI (v2):
- 8+ more buttons? 800x600 or less resolution? No problem anymore! The buttons wrap and the app scales.
- Templates/Skinning support
- No more color coded buttons (in default templates)
- Redone UI in my template won't have the hover bug for tooltips (mouseout from inside AIR app, thinks you're still hovering)...AIR 2.0 might fix this on its own.
- On-the-fly template switching
- Refactored object class
I might add a graph rendering to display current stats for the day too as I've been asked for it, but it wasn't meant to view reports, only create the data used for them. This seems less important to me than the user interface and code updates though (template/skinning was so users could switch between horizontal and vertical displays depending on their desktop icon arrangements or resolution).
Current mockup (without tooltip) rendered by Safari 4.0.5 for Windows.

Reference Statistics Tracker for SSPL v2
I never claimed to be a UI designer.
jQuery Printed Footer Links
I was randomly perusing the web and stumbled across an older interesting List Apart article (September 19, 2005 to be exact). In it, the author used JavaScript to create a list of all links found on the page, and then create a footer with a footnote-like list. I was using simple CSS to display the URL of the hyperlink in print display media, but that doesn't work in some browsers (IE), and worse off it can really mess up the visual order of the page.
Inspired by the article's intentions, I decided to use some jQuery to whip up a similar solution and I took the opportunity to use jQuery 1.4's new syntax for object creation (so this is 1.4 code only - see comments for a 1.3.x solution). Differences? I exclude hyperlinks set to the hash symbol (#) which shouldn't be found anyway (graceful degredation people!), "mailto" links, and I don't find link element's citations (blockquote "cite" property). I also believe his script would grab image information, but I'm not entirely sure, mine only searches hyperlinks. I also opted not to exclude listings of duplicate hyperlink values. If it's found twice, it lists it in the footer twice. Less JS processing, and more clear to the visitor (in my opinion).
Expected Issues: It requires JavaScript (and the jQuery library included on your page). If JavaScript is enabled but CSS is disabled, the hidden content will be visible to the user.
On to the code!
First thing's first, we should find the links in our code that we'd like to target. For my situation, I have a content class defined on my page for all content, and the column that contains the actual body is called ".col2_right" (yes, I know, ignore the fact of the poor naming scheme). So, in jQuery, we're going to target all hyperlinks found in the col2_right and content classes, but we don't want to include links to hashes or mailto links. I've also removed listing to nofollow links, but that is my choice (probably not a good one, but I digress).
We'll also need some sort of container to keep these found links wrapped in. I chose to use a fieldset and legend, you could just as easily create a DIV and a H2 or other tags for your own purposes. I also want to create an ordered list to match the found hyperlinks.
Here comes the real center, meaty goodness of the script: looping through our list of found hyperlinks, creating a little notification text next to the hyperlink's text, and add the hyperlink URL itself to the footnote section in the ordered list as a list item.
We use jQuery's each() method to loop through the items in the array, grab the link's URL so that we can do some testing on it, and modify it's value for inclusion in to the footnotes. Some links may be relative URLs, but that doesn't mean much to someone who doesn't know what a relative URL is. In fact, it would probably confuse me too at first. I happen to know that my domain forces www for the subdomain so I've added that in, fix that up as you like. I then create a span tag to hold the associated footnote number (the ListApart article used a superscript tag, I found regular text is more easily readable), add a class to it so it's only visible when printed, and create my list item element with the URL from our link, and place those elements in to the document in the appropriate places with the appendTo jQuery function.
Last but not least, we append our entire footnote to the end of our content body section. The full code is below.
Note the added "if" statement to check the length of the links variable. If it is empty, we did not find any links and don't want to create any extra markup when printing the page.
Oh, and the CSS: ".print_only { display:none; }" This should be placed in your normal style sheet, and leave it out from your print style sheet. If you don't have a print style sheet, extend it a bit: @media print { .print_only { display:none; } }
Note: Thanks to Stiles to provide some fixes and compatibility changes for jQuery 1.3.x.
Inspired by the article's intentions, I decided to use some jQuery to whip up a similar solution and I took the opportunity to use jQuery 1.4's new syntax for object creation (so this is 1.4 code only - see comments for a 1.3.x solution). Differences? I exclude hyperlinks set to the hash symbol (#) which shouldn't be found anyway (graceful degredation people!), "mailto" links, and I don't find link element's citations (blockquote "cite" property). I also believe his script would grab image information, but I'm not entirely sure, mine only searches hyperlinks. I also opted not to exclude listings of duplicate hyperlink values. If it's found twice, it lists it in the footer twice. Less JS processing, and more clear to the visitor (in my opinion).
Expected Issues: It requires JavaScript (and the jQuery library included on your page). If JavaScript is enabled but CSS is disabled, the hidden content will be visible to the user.
On to the code!
First thing's first, we should find the links in our code that we'd like to target. For my situation, I have a content class defined on my page for all content, and the column that contains the actual body is called ".col2_right" (yes, I know, ignore the fact of the poor naming scheme). So, in jQuery, we're going to target all hyperlinks found in the col2_right and content classes, but we don't want to include links to hashes or mailto links. I've also removed listing to nofollow links, but that is my choice (probably not a good one, but I digress).
We'll also need some sort of container to keep these found links wrapped in. I chose to use a fieldset and legend, you could just as easily create a DIV and a H2 or other tags for your own purposes. I also want to create an ordered list to match the found hyperlinks.
Here comes the real center, meaty goodness of the script: looping through our list of found hyperlinks, creating a little notification text next to the hyperlink's text, and add the hyperlink URL itself to the footnote section in the ordered list as a list item.
We use jQuery's each() method to loop through the items in the array, grab the link's URL so that we can do some testing on it, and modify it's value for inclusion in to the footnotes. Some links may be relative URLs, but that doesn't mean much to someone who doesn't know what a relative URL is. In fact, it would probably confuse me too at first. I happen to know that my domain forces www for the subdomain so I've added that in, fix that up as you like. I then create a span tag to hold the associated footnote number (the ListApart article used a superscript tag, I found regular text is more easily readable), add a class to it so it's only visible when printed, and create my list item element with the URL from our link, and place those elements in to the document in the appropriate places with the appendTo jQuery function.
Last but not least, we append our entire footnote to the end of our content body section. The full code is below.
Note the added "if" statement to check the length of the links variable. If it is empty, we did not find any links and don't want to create any extra markup when printing the page.
Oh, and the CSS: ".print_only { display:none; }" This should be placed in your normal style sheet, and leave it out from your print style sheet. If you don't have a print style sheet, extend it a bit: @media print { .print_only { display:none; } }
Note: Thanks to Stiles to provide some fixes and compatibility changes for jQuery 1.3.x.
Website Render Time with PHP >= 5.1
In CakePHP v1.3.x, there will no longer be an automatic dump of tons of information (probably because the DebugKit plugin can handle all of that information for us) when in debug mode. However, in my non-CakePHP websites, and even in my Cake websites, I have become accustomed to viewing the source to see a full render time for the page in an HTML comment. Thanks to the help of "jnay" over at CakeQs.org, I've found out about a new (as of PHP 5.1) $_SERVER variable argument called "REQUEST_TIME". It holds the UNIX timestamp of the initiation of the call.
By using this variable, along with the optional boolean argument for microtime (as of PHP 5.0.0), we can determine the HTML render time of our application with the following calculation in either our footer view/template, or controller (preferably in the last possible iteration of your project's render):
The echo is optional and used only as an example here; it simply depends on how you use the calculation in your script(s)/framework(s). This is much easier than starting the timer in the header and calculating the difference in the footer like I had to do in the PHP 4 days!
Remember, this is only for trivial estimations and comparisons. If you need to thoroughly evaluate your script(s) for time efficiency you should be using something else, such as Xdebug and a form of CacheGrind for your choice of OS.
By using this variable, along with the optional boolean argument for microtime (as of PHP 5.0.0), we can determine the HTML render time of our application with the following calculation in either our footer view/template, or controller (preferably in the last possible iteration of your project's render):
The echo is optional and used only as an example here; it simply depends on how you use the calculation in your script(s)/framework(s). This is much easier than starting the timer in the header and calculating the difference in the footer like I had to do in the PHP 4 days!
Remember, this is only for trivial estimations and comparisons. If you need to thoroughly evaluate your script(s) for time efficiency you should be using something else, such as Xdebug and a form of CacheGrind for your choice of OS.
(Page 1 of 1, totaling 3 entries)

