Tuesday, September 23, 2008
The thing to realize is that this is by no means a static graph. It is always accurate to the states and numbers of items in the select box (even if you add or remove items).
Granted, it took some time even beyond that demo to get the css to work. I had to deal with max-height, and list-style-type, and it took some time to wire the logic into this chart, but the results are enjoyable. The demo here is relatively positioned, but you can tell this graph and even the dropdown (or a mix) to be absolute, and it will coast over the text instead of pushing it aside. I have it relative for the demo.
The way I have this written, and with the options I added, you can use any labels and build up to 5 states, which hopefully is plenty. You can use any colors too, but the css demo uses background-position for the colors, so you will need to update a very small image. I will be building a skinning set so you can simply choose your color theme and away you go -that is not there yet.
The graphs are the default css colors and image from the site, but they are configurable, and the labels are no longer built into the image.
Sunday, September 21, 2008
Otherwise, see 2.0 below:
Welp, i'm finally done transforming the code to be usable as a tool if you have jQuery 1.2.6+. I've spent many a week trying to perfect this in various browsers, and compiling a help guide.
Please see this link for everything you need to know.:
Select Box Factory 2.0 for jQuery (Help Guide & Download)
(give it a second to load, i've added a ton of dropdowns and code for examples in an accordion widget).
Sunday, September 14, 2008
View log in action and learn about all options and settings.
download v1.2j (as of 9/14/08 1:57pm)
View 1.2j log in action.
- Version 1.2j is new and uses uses jQuery 1.2 and the jQuery ui draggable code, and has a slightly different UI. Supports IE6+, Firefox 2+, Safari 3+, Opera 9.5+, Chrome 1+. The log.js is also about 5k smaller, for essentially the same code, but required more k of plugins.
View 1.2 log in action.
- Version 1.2 uses uses mooTools 1.2 and has more features, seen in the above link. Supports IE6+, Firefox 2+, Safari 3+, Opera 9.5+, Chrome 1+.
View 1.1 log in action.
- Version 1.1 is deprecated and uses mooTools 1.11 and has less features. You can't use the resizer, there are more visual bugs, and a few display options are missing. You can still use it for development with mooTools 1.11 here.
- Future fixes: will use position: fixed (not for ie6) to stop redraw flickering.
Wednesday, September 10, 2008
Everything grayed out is now completed in version 2.o, at the top of this blog.
- Port over to mooTools v1.2 (possible future version)
- Port over as a jQuery 1.2. I've converted my first widget to jQuery and the transition was not bad.
- The ability not to have to use ctrl key to add options to a multi-select box, although I will leave shift alone. (version 2.1) Also, somehow something for mac users, who have the command key...?
- The ability for the user to expand or collapse the box as they see fit. It would literally be a pliable, resizable widget to let users see more. This will be available in limited scenarios.
- The ability to invert selections. (version 2.1)
- The ability to emulate and take optgroups. (version 2.1)
- performance and display enhancements.
- Eliminate the need to have any divs in the HTML to create a dropdown dynamically. I thought i had this covered, but it needs a few more tweaks. Apparently you still have to have 2 divs on the screen. I will clean this up asap.
- I was considering also showing how you can use Ajax to load the dialog. I do this at work, using HTML but you can also parse XML or JSON (using mooTools), and I can show examples for how both are done. (version 2.1)
- The possibility of a history... recording last few items found (for the sift tool). This may be too much. (possible future version)
- I thought I might also show the dropdown being used inside a dialog. You may have some trouble getting these to work positioned absolutely, and I can show how I've solved this problem, even getting dropdowns to stack with zIndex so they don't open under each other.
Sunday, September 7, 2008
Here is the summary before the breakdown. All complex systems, and i mean ALL complex systems have their form of "bugs", or deviations from the norm - since this is the nature of the universe. Seen from that most generic point of view, bugs are inevitable, unavoidable and often times expected.
Software exhibits bugs when...
- the use cases driving the software are not fully understood or change during development.
- the code is too rigid - lacks flexibility and robustness
- the developer uses bad practices and makes it hard for new developers to read and use the code, or even himself 6 months down the road.
- there are too many levels of communication in the stack of code, or layers of indirection. Concepts degrade from receiver to receiver resulting in corrupted information.
- the long and complicated string of logic required for development is somehow interrupted.
- any many more... please read on for a comprehensive set. I don't think this is really in any order yet.
- Time is both the whip that prods the engineer and the pressure that cooks the engineer from coal to a diamond.
- Learning how to code with time constraints forces the engineer to gain efficiency - which means less code and less bugs : elegance. And as we all know, the best code is elegant code. Elegant code is the holy grail of development. It is not the end goal, rather, functionality is the end goal, but elegance is the grail.
- Time, however you look at it, is a force exerted upon the developer. Decisions must be made, often without the time to follow those use cases to their best end result. Because of this, the core of the system design, no matter how small - is naturally going to suffer in the realm of robustness and flexibility. When these two attributes suffer, the possibility for that or other developers to add buggy code is higher.
- A separate metric here is experience - time as related to experience shows (graphically) that as the experience of the developer grows over time, the likelihood grows that robustness, flexibility and overall elegance of the system will be in place before the product is released.
- Bugs are possible even when a developer is focused on one project - but this is rarely the case. Often times, and especially in an environment that lacks sufficient talent for so many burgeoning new projects, developers are forced to do more than one project at a time. The same resource must be divided amongst many projects and this leads to the lack of sufficient time, and lack of time leads to bugs.
- I consider this to be a constraint. Lack of knowledge here is not lack of expertise. The knowledge here is twofold: knowledge of what the use cases are that the software should support (in use-case driven engineering) and the overall knowledge of the group within engineering - the engineer's surroundings.
- The first aspect, use cases, shows us that bugs can get into software when use cases are either not fully understood by the engineer for whatever reason or when use cases are introduced, and then changed over time.
- The second aspect, surroundings, shows us that bugs can be introduced when the engineer is working in a team, but for whatever reason is not synchronized with that team in terms of his or her knowledge - the knowledge about exactly what everyone is doing. This can happen over long development cycles. Again, the engineer has to backtrack or modify the code, resulting in bugs.
Use case changes, scope creep
- Changes in use cases often times happens during the product development and causes many bugs. Use case changes are the most dramatic and damaging of all possible ways that bugs can be introduced. This can happen when those responsible for the use cases of the software suddenly realize that they were wrong, the customer was wrong, or that the use cases outlined are not enough.
- Bugs beget bugs! The biggest reason why bugs cause bugs is because of the inevitable lack of robustness or lack of elegance in code. When a developer has to fix a bug, it is very, very likely that they will fix one bug and cause another. This has to do with all of the bullet points listed on this entire page.
3. Emotional Coding
- Even the most hard-nosed iNTJ, introverted genius savant will have some aspect of emotion in their code. We are emotion and logic driven creatures. Because life outside of the world of development is full of complexities, it is nearly impossible to remove all that when you code.
- Anger, lust, lovesickness, spite, joy, disgust or overwhelming glee can occur even when developers are in their Coding trance. All of our bodily movements, and even our ability to formulate logic are driven by emotion of some kind, even at the most animal level - for we are fright-or-flight creatures first, and rational man second. Even the brain shows us in its structure hierarchy that reason and logic are built upon the concepts of movement, lower-level emotion, and survival.
- So what does all this emotion mean? Everything. There are only so many keys on the keyboard to press in order to input characters to the screen which will ultimately become code. The neurons that fire to command your fingers to code logic one way versus another is entirely subject to the current emotional experience of the developer. Trances help to limit this kind of development, but can't be removed entirely. As a result, and over the lifetime of the software development, there are subtle variations in the robustness and flexibility of the code.
Other projects, part 2
- Bugs are possible even when a developer is focused on one project - but this is rarely the case, as I said already. Switching gears between projects increases the likelihood that ideas will be forgotten and deviations from robustness and flexibility will increase. This is a fundamentally different problem than simply having more than one project. In other projects, part 1, I outline that the division of a resource across projects reduces time per project. Here I am saying that switching gears among projects leads to confusion, inefficiency and ultimately to stress and emotional coding.
- Those darn other humans! They keep taking me out of my coding trance! This leads me to code more emotionally. This leads me to distraction. Distraction helps ensure that I will forget the very long and complex string of logic I had to create in order to make the software work. This is a necessity in the work place since no man is an island. We work in engineering teams and must be able to focus on other people.
- Noises, especially these days are at an all time high. People take for granted all the clicks, beeps, boops and rings that are in the office environment. It is often true that people with the talents of coding exhibit traits of introversion (but not always), but also traits of sensory sensitivity and enhanced abilities to view systems as a whole, assemble and disassemble complex patterns, and abilities to string together long strands of complicated logic. The same systems allow engineers to be easily distracted by impurities of environment. Impurities, like real flying bugs, destroy the experience.
5. Levels of Expertise
- Achieving any level of homogeneity in an engineering team regarding experience is tough - but well worth the effort. Having most of your developers at roughly the same level of experience will ensure that they are all playing the same game. Can you imagine if a baseball team or a football team was forced to play their weakest players at all times? In the office, we can bench our weakest players, but in the end they are touching code and inexperience means bugs. Nobody is sitting on a bench doing nothing or they would be let go in the blink of an eye.
- There is not much else here to say. The more experienced you are, the more likely you are to write sustainable, robust code. The less experienced you are, the more likely you are to write inefficient code which leads to bugs.
Complexity of the system
- This could be considered a constraint, but there are many levels of communication in the average stack of code. From the thinest user-interaction layer of the browser, to the business logic, to the database, often times there are 3, 4, 5, 6 or more layers of independently self-sustaining software platforms or "tiers" that make the software run. And that is just the software that is being created. Imagine all the layers involved when software is installed into software! The fact that anything works is nothing short of an absolute miracle. Very few non-developers will truly appreciate this.
- Concepts degrade from receiver to receiver resulting in corrupted information. The bible lost a lot of its original meaning when translated from language to language over the course of thousands of years - and the analogue of bugs here is the mistakes of interpretation
When it comes down to the nitty-gritty, development, as in life shows the true nature of the engineer when things aren't going well. We do get credit for our ability to plan, but the true measure of an engineer comes when forced to deal with the inevitable bugs that arise from their or some other software.
"It's not about how you plan, its about how you deal with crisis."
Friday, September 5, 2008
It wouldn't be fair if I didn't at least try to deduce why on Earth CVS decided to use such wasteful and useless packaging. The almighty dollar is at play here, because logic, common sense and consideration are certainly not. Here is what I came up with.
- CVS came out with this to compete with Zyrtec, and Zyrtec has quite flashy packaging. Its possible that they needed a larger box to ensure fair product placement in the aisles. Is that the reason? Then consider my idea below.
- Merely one cardboard slab, held in a slot above the price, yet in front of the product, but just below it, would emulate the experience of fair product placement. Behind this are all the little bottles on their own. Saves space for more product. Saves cardboard, recycling, money and my sanity.
If you think, like I do, that the above is bad, then consider Prilosec. First, the amount of packaging...
Second, the amount of actual product. YES, thats it. All these pills came from that pile above. Read on....
I do rely on these medications to some degree, so I am thankful they are there - don't get me wrong. However as someone who has devoted much of his life to improving interfaces, I have to say that I have similar concerns about waste in developing software.
The concerns are aligned when i consider the sheer weight of the pages the user has to download - and the speed at which the browser must render the page. The slower the experience, the worse off we are at selling the product.
As a designer and as an engineer, I am always on the search for the simplest possible solution that gets the job done - so the above pictures are nearly criminal to me, and cause me a certain amount of grief.
Things like this are why I got into the industry in the first place - but it wouldn't be fair if I didn't say that there is less red tape working for a software start-up, then there is for an international multi-billion dollar consumer product company.
I don't like to complain without viable solutions, so I have offered one. My solutions map to what I believe the problem to be. Lets face it - the marketing department at CVS has a lot less money to play with then McNEIL-PPC, and so I assume CVS would prefer to keep their costs down in this manner. Is that a correct guess? Maybe the opposite is true. maybe CVS has money coming out the wazoo. Then, to that I ask.... why such minimalist and boring product design? (do people want boring when it comes to generics? Perhaps!) Again, maybe I'm wrong about that. Regardless, my solution is one of many and geared towards the problem I think is at hand.
Behind closed doors there are concerns I am not privy to as a consumer. Deadlines, management breathing down your neck, serious budget shortages in a down economy, not to mention the myriad of issues around safe packaging (with the litgious nation we are), as well as distribution problems. Let us not leave out manufacturing. All in all it's a magical dance where all the partners in play somehow manage to produce a consumable that we all take for granted.
Thats a fair, if not overly-simplified view of the whole thing, right?
Still... it eats away at me that this couldn't be done better. I think someone tried... maybe that one maverick who said "why the wasteful boxes?" was shut down by management with other concerns, and he moped his way home hating the world. Maybe that happened.
For CVS, I say just sell the damn bottles on their own.
For Prilosec, I wonder why they can't put these pills in bottles. Do we really have to safety seal each individual pill? Is it because the product has a short shelf-life? Is it because *the perception* of sterility is what the consumers want? I don't know, and again, there is more at play here than mere logic.
So coming in from left field, I would offer a variety of solutions that address these concerns and yet allow maximum profitability. Hopefully, these changes reduce manufacturing costs, while appealing to the current green market.
For Prilosec, I offer the Mentos platform. Yes, the candy pictured here.
This brilliant candy roll style has been popular since candy was invented. Yet Mentos one-ups the competition with foil. Yes, the same thin metal that gives many products the appearance of sterility.
While the amount of real estate for marketing is low, can't you see the benefit of Prilosec putting their pills into foil like this? And in each 1/4 sized box is 3 of these. People can stuff them in their purses or backpacks. It gives the sense that the user is eating candy and takes some of the more medicinal aspects out of the picture. Is that not a good thing? Well, what do I know.
The difference here is that betwixt each oblong shaped acid-reducing tablet is more of the foil. You see, instead of each pill bumping up against each other - simply add a thin sheet of foil between them. Same sense of sterility. 1/4 the packaging or less.
Want to market them better? Then put them in one of these cases at the end of the aisles. There are a million ways to market items in a store - but overly wasteful packaging does not and should no longer be one of them!
Monday, September 1, 2008
See Select Box Factory 2.0 for jQuery
Download v 1.0
Here, the factory has produced a multiple-select box, with "sifting" tool attached. Try searching for one of the items in the list, or typing a letter in there. Next to it is the exact same list rendered as a dropdown (takes about 5 seconds to make this transition).
Why not cram some images in there? Here are images representing ranges, so search for "upper" for upper range, and see what happens:
Or what if we took the first two examples, but this time made the first list a "select-one" list, but wanted it to be open? And maybe we don't want the eraser in the dropdown on the right... and for some reason we also want a count at the bottom.
Select-ones with toggles, like on the right side are one of the weirdest variations and I recommend not to use them, but they are there. Because they are not dropdowns, the selections do not cause the toggler to "snap" back. To do this, you make it a "dropdown".
Next is an example of a select box whose elements were not found on the page, but rather in the definition. Inside the JSON object called "definition" is a child JSON object called "choices". The order to add items was specified as ascending (descending is also possible).
The code won't sort a list for you - it assumes you know the order. Try adding or removing items below, and have a look at the code in the zip file for more. Remove does remove a predefined item, but its nothing to make this remove selected items or based on a passed-in value.
But wait... its gets even more interesting. I've added the ability to show and toggle a certain number of states. I call this a heatmap, and it has many uses. Let's say you retrieve items where some are errors, some are warnings and some are info messages. Not only can you filter on those states, you get convenience buttons too. (unfortunately, there is not a lot of room for the buttons to have text). The states are numeric (0-5), so the buttons are nice when the users don't know the states - its more visual than anything.
All you have to do is add a state property to your items as an attribute, and boom, the code crawls over your items and figures out all the states on its own. It may be tough to see the selections here, but its up to you to skin these the way that makes sense to you. Add any colors that you want. Whether to show the convenience buttons or not is up to you. These work up to a point - since your dropdown can only be so wide. The code does its best to fit them in based on your css styles. For now, the states are numeric no matter what.
Try this: in the box on the right, first click the yellow button, then type "J" in the sift box. Its a filter within a filter.
Then try this: Click the eraser to clear the box, then click the yellow button again. Except this time, in the box, add "|v" (without quotes). The box should read 2|v. See what happens. (| pipe means "or")
Above you see some of the many variations that are possible with the select box factory. You see a multiple-select box opened with a max size of 6, that is capable of using the sift tool. Here are some ways to test its capabilities.
- Try using control key to choose items like you might in a normal select box. Do this on the select-multiple boxes.
- Use the shift key to do the same.
- Click the eraser and see what happens.
- Type something in the text box and see what happens.
- Try typing the letter I while focused in the box and see what happens.
Download v 1.0
Results of performance testing
About the tool in general
- Uses divs instead of options, which is why the potential for extension is nearly unlimited.
- Does whatever a dropdown can do, but goes far beyond.
- It is easy to call up a dropdown, assuming you have a div on your page that you are using as a dropdown.
- All variations can fit a container, whose style you must supply in css, or it can live by itself, using itself as a container.
- All variations are relative positioning, but work great positioned absolutely, or stacked on top of each other with z-index. This is up to your css and design, but they fit well. The above examples have a lot of whitespace because I am showing them inside iframes with the iframe border turned to no/0.
- All variations can be enabled and disabled.
- All variations are very, very easy to style in css. Just edit selects.css and you are done. You can even style the scrollbars if your browser supports it. (I suppose the ultimate incarnation would not even have that overflow scrollbar, but its not as easy as it looks to make one work without using overflow this way - its not something I am going to work on.)
There are three major variations to this..
- works just like a standard javacript dropdown
- can take images, which dropdowns can't do.
- can show as many items before rendering a scrollbar as you want.
- has a neat eraser icon so you can "undo" your selections. normal dropdowns don't do this, but I think they should.
- It will allow you to show it opened or closed by default, which dropdowns today can't do. This is neat, because you can "show your users" an interface you want them to touch on the onset.
- All variations can show a count of what is selected, but only the toggle versions (select one, and dropdown) will show you in text form what that select is at the top.
- All variations will seek out and highlight the first item in a list based on the key you press. (although i don't have this working in safari yet).
- My favorite variation, shown above.
- You can put a sift tool on top of it for nice searching.
- You can put no toggle or sift on it, so it looks like a normal dropdown.
- It uses spreadsheet style selections.
- very much like setting a select box to have a size of 1, this variation would be less common but has a ton of uses.
- This isn't a dropdown, but can act like one. The biggest difference between this and a dropdown is that a dropdown snaps back and this one stays open.
Needless to say, there are a wide variety of ways to use these dropdowns and I hope people find them intuitive to use. They are part of a more extensive "ui factory class" that I have created to plug into mooTools. This select box factory is enough for now.
(It expects mooTools v.1.11 but honestly, the only real neat effect is a toggle() so this can easily be ported to mooTools v1.2).
I will be fixing bugs and enhancing performance in the weeks to come to make them even faster.