Never Argue With Stupid People

Hi All,

As a Microsoft Student Partner, I have the inside track on the best student resources that Microsoft has to offer. And I want to share them with you.

Today, I urge you to check out Microsoft Students to Business (S2B). Why? Because, like me, you’re probably either looking for a job, or for experience/internship so that you can land a job when you graduate. S2B offers students:
• free training (everyone needs skills in today’s hyper-competitive job market)
• free software (how can you practice those skills without software?)
• experience (projects, internships)
• JOBS!!! (Microsoft’s partners post 1000’s of jobs for entry-level candidates)

Microsoft S2B isn’t just a job site. It’s a launching pad for your career. With free Software, Skills, and Experience up for grabs, you can get everything you need to set yourself apart from the pack. And with plenty of access to jobs and internships, you can take your new arsenal of know-how and land the job of your dreams. Don’t postpone success, register today: http://s2b.experience.com

Joining is easy, just fill out the quick/short registration form. If you have any questions…ask me!

Tweet This Post

This post is more of a record for me because I have run into the same issue several times. And the title is misleading because it should be more like assigning listeners to dynamically generated buttons of varying quantities. OR something like that. Anyway, for those that use Javascript allot, this is no-brainer territory. For me however….

Anyway, I am parsing datasets from biomart.org, and part of the data set contains a collection of attribute groups. Each attribute group has a button assigned to it that when clicked, displays attributes assigned to that particular group. I know, YAWN!

Here is my initial function that I was using to create the buttons and assign the listener:

function buildAttGroups(attData){

        var idLabel = attData[i].displayName.replace(" ", "_") + "_content",            button = new Y.widget.Button({                                id: attData[i].displayName.toUpperCase(),                                label: attData[i].displayName.toUpperCase(),                                container: attButtonGroup                                }                );

        //other irrelevant code

        button.on('click', function (e){ setVisibility(idLabel);});

    }

The problem here is that no matter which button I click, idLabel is always equal to the idLabel created when the last button was created. If you are coming from a java world, that may be a bit surprising because you may expect that each time a new button is created that a new listener is being assigned to it. From my understanding however, there is only one listener created, and it ends up being assigned to each button. Not at all what I want to happen.

The solution is simple. Create the listener in a separate function.

setVisibility(button, idLabel);

......

function setVisibility(button,label){

        button.on('click', function (e){                obj = document.getElementById(label);                obj.style.display = 'block';

             });

    }

Now next time I screw this up, I’ll remember what I need to do.

Tweet This Post

I saw this on Reddit the other day, and it reminded me of the rather unrealistic expectations people have when asking questions.

“I don’t want to build anything too complex. It doesn’t need an automatic transmission or air conditioning. I understand that most of you engineers have a few years of experience and education behind you, but, can you point me in the way of some quick tutorials? It has to be street legal and safe. I know nothing about cars or engineering. I’ve got a month to build it.

I got a steering wheel from a junker so I figure that I am halfway there already.”

Some of the replies were pretty funny also:

“Me 2. Plz send completed car to sunforum99@yahoomail.com.”

“I know where you can get one, but it only drives backwards, simply stops if you put it on an interstate and there are no locks on the doors. You could still fix it yourself, though.”

Tweet This Post

Last spring I was fortunate enough to attend MIX09 courtesy of the Microsoft Student Partners program. In addition top being blown away by the lavish surroundings, I also learned about this thing called User Experience. Truth be told, I was a little overwhelmed by my surroundings and all of the activity surrounding the conference that it was difficult to digest all of the information and hype, so it wasn’t until I got back to school that I was able to sort of think about what I had learned. When Bill Buxton unveiled this innovative product called Sketchflow and talked about how it would bring about better user experiences, I could see what an exciting app it was, and that it would clearly be fun to use. The emotional aspect was lost on me.

One of my professors teaches Human Factors, and I talked to him about what I had learned and seen, and we discussed this idea of user experience, and how important (as I had been told) that designers be brought in early into a project in order to provide a good user experience. We agreed at the time that this term, User Experience was just a new buzzword for human factors.

My last few blog posts were about a mobile application that I developed as part of an independent study that allowed me to study some of the special ‘problems’ associated with mobile application development. One of my main resources was Mobile Design and Development by Brian Fling, and in it he talked about the design process. I do recommend the book.

There were two concepts that struck me. The first was when he talked about not considering the inherent constraints of designing an application for a mobile device. At the time, it made no sense because I thought “why try to do something if I know the hardware can’t handle it.” The second concept was this idea of context. During this design phase, I need to consider how the app is going to be used, as well as where, when, and by who.

As I started thinking about my app, it became clear to me that I need to design it to be used in short bursts because a student would potentially be using it on the way to class, or during a walk in the park, for example. this meant that the system needed to do frequent saves the state of the application, and be easy to resume. Simple enough to do. I also want to make using the app a social event, so I want my user to be able to share data.

As I was considering all of these ideas, what I was really doing was systematically working through ideas that would make the application fun to use. It is sort of a no-brainer that regardless of the functionality an application provides, if it is painful to use, then nobody will want to use it. So what I was trying to do was make my application fun to use. It was at that point that I suddenly had a couple of revelations about software design.

First, while I was working through what I wanted the app to do, at no time did I consider whether or not the hardware could handle it. The first time that sketched out the design for my app, I spent too much time thinking about things like screen size, and navigation, etc., and I think that by considering the limitations of the hardware, I automatically limited how I thought about the functionality of the application. Clearly the time to worry about hardware limitations is during the development/implementation phase.

Finally, while HCI considers things like the physical and psychological capabilities of people when designing systems, user experience is much more encompassing because it considers the impact of emotion and context. As I said before, an application can have all of the functionality in the world, but if it isn’t any fun to use, then nobody will use it. If you can make an application fun, functional, and ‘sexy’, then you have a home run. Anyway, it changed how I view the design process.

Tweet This Post

GENERAL DESCRIPTION:

• This is the screen where an actor can add cards to a set.

ACTOR:

• The actor is a student.

GOAL:

• The goal is to allow the actor to create a card set.

PRECONDITIONS:

• The application must be running.

POST CONDITION:

• The actor has successfully created a card and added it to a set.

SCREENSHOT:

OBSERVATIONS:

This iteration is terrible. There is too much happening on the screen, and there is no room for labels, so it is unclear what the user is supposed to do. There is a box for a save name, but I think the better idea would be to move that functionality to a different page. Some may expect that there would be the need for a ’save’ button, or that it may be hidden under the menu button, but that is not the case. Since I expect the application to be used only for short bursts of time, every time a card is created, it is automatically saved, thus there is no need for a save button.

The second thing is that the edit card set screen and the create card set are nearly identical. By moving some of the functionality, I only need to create this form once.

REFINED SCREENSHOTS:

This is better, but I just noticed that I forgot some functionality. There is no way to navigate to the next card in the set. Now I have to take an inventory of necessary functionality.

• Back and Forward buttons: necessary because the user needs to be able to navigate back and forth in a card set.
• Text Block for the question
• Text Block for the answer

The only thing probably not needed is the breadcrumbs. I could place a button in between and drop the breadcrumbs, like so:

This is better, but I don’t like having the ‘Next’ button at the top because it breaks the flow. Order of operation should flow from top to bottom. However, moving all of the buttons to the bottom does not seem like a good idea either because then the navigation buttons are down by the function buttons; it seems that the potential for hitting the ‘Exit’ button instead of the back button is too great.

I looked back through some flash cards that I created using Index cards, and I noticed that generally, the answers were very short, and that the questions were not too terribly long either. This suggests a bit different layout that might be acceptable:

This layout works a bit better because now the ‘Next’ button is at the bottom where it makes sense, and it is also along the side so that it is easily operated with a thumb. There is also little danger of missing the button, and even if the user does, all they will do is hit the ‘Menu’ button. It also suggests some ideas for graphical design that may be interesting. So now the complete flow for the user is like this:

FINALIZED SCREENSHOTS:

Tweet This Post

GENERAL DESCRIPTION:

• This is the central navigation screen first presented to the actor after the splash screen.

ACTOR:

• The actor is a student.

GOAL:

• The goal is to allow the actor to begin one of several activities.
  • Create card sets
  • Update card sets
  • Review card sets
  • Share card sets

PRECONDITIONS:

• The application must be running.

POST CONDITION:

• The actor has chosen an activity.

SCREEN SHOTS:

OBSERVATIONS:

The first iteration is just a simple button layout. I see two disadvantages to this style. First of all, it is sort of plain. The button size also may make it hard for some users to accurately make a selection. The second and third options are a little more stylish, and feature oversized target areas that make it easier to make a selection.

The second problem is that if I want to add features, I have to consider that I may need more buttons. Again, with the first iteration, adding buttons means that the button size will be reduced, again affecting accuracy. The second and third options are still the better choice because of the oversized target area. If necessary, I can decrease the target size slightly without accuracy being compromised.

To further narrow my selection, I also consider how users interact with their mobile devices. Since people tend to use their thumbs, it quickly becomes apparent that the second option is best because the target areas on the sides are easy to reach.

The final problem, and not one I am going to address in this version of the application, is how to handle screen orientation. My plan is for the device to be used in portrait mode. Eventually though I am going to want to consider how the layout looks in landscape mode.

PORTRAIT MODE:

Tweet This Post

I am doing an independent study this semester regarding developing for mobile platforms. Mainly I am looking at the differences between conventional development, and mobile development. Since I have not been keeping up on my blog, this seemed a natural place to keep track of what I am learning. Here is the second ‘installment.’

*****************************

Context

Another consideration when developing for mobile devices is to consider the context. Author Brian Fling, in his book "Mobile design and development," views context in two ways; context with a capital ‘C’, and context with a lower case ‘c’. Context, with a capital ‘C’ is taken to mean how the application ‘enhances one’s experience and awareness of surroundings.’ Context, with a lower case ‘c’ is taken to mean the environment, or setting, in which the application is going to be used.

From my perspective, Context is something that comes into play before an application is even created. Once we have an idea for an application, it then becomes context. I already discussed the limitations of various devices, and how those limitations drive design considerations. That can be considered hardware context.

Some other contextual considerations:

• How the application will be used
• Where the application will be used
• Frame of mind when using the application
• Other hardware contexts

How the Application Will Be Used

The application that I am developing for this class is a simple flash card application that I can use between classes to study. So right off the bat, I have a few considerations. First, it needs to be simple to create and edit a set of flash cards. Since I will likely only be able to use it for short periods of time, the application needs to be able to save my progress. I also want to be able to track my progress, so I need to keep a running tally of how I am doing. Finally, I want to be able to randomize the card sets when I review them, and I think I want to be able to share card sets with my friends

One of the more challenging aspects will be to allow for simple creation and editing of card sets. One my Fuze, I have a built in keyboard. My Zune does not have a keyboard, so I will have to hook into the touch screen keyboard. What if the device does not have an on-screen keyboard? Then I will have to consider creating my own, and I don’t know that I necessarily want to do that. Editing a card set uses basically the same interface as creating a card set.

Where The Application Will Be Used

For my application, I expect it to be used between classes for short periods of time, and when studying for tests, longer periods of time. From a more practical standpoint, I have to consider that I may want to sit outside and study. I also have to consider that there may be a variety of distractions. Right off, that suggests three constraints.

1. The screen must have high contrast. For daylight use, I want light backgrounds and dark elements.
2. I want to color code actions. While I want to limit my palette, I want to unify elements. I want elements related to input in one color, navigational elements another color, etc.
3. I also want to keep the layout simple and consistent between pages. It goes without saying that if navigational elements are at the bottom of the page, then they need to be at the bottom on all of the pages.

Frame of Mind

Brian Fling calls this modal context, and I had sort of a hard time understanding this at first. The best that I can understand is that this represents the desire of the person who is using our application. In my case, I want the person using the application to be a more successful student. As such, I want to consider those elements and situations that would prevent a user from successfully using my application. If I know that the user is going to have limited time, then my application has to be responsive, and allow the user to quickly navigate to the desired function. I also have to make sure that the application functions in a consistent manner. Finally, I need to make sure that the user is getting feedback that helps them reach their goals.

Other Hardware Contexts

I covered hardware constraints in my last post, so I will only touch on a few other things that I think are important. Will my user be using my application in landscape or portrait mode? Can I use functionality of the device to make a better user experience?

Testing for context

Brian Fling has an extensive list of context tests. I’ll list a few here:

1. Does the application load quickly and correctly?
2. How long does it take before the application can be used?
3. Does the application terminate properly?
4. When another application interrupts, what happens?
5. Does the view change when rotating the device?

Some interesting links:

http://pkruchten.wordpress.com/2009/07/22/the-context-of-software-development/

I need to put in a plug for "Mobile Design and Development," by Brian Fling. It is one of the few books that I have read that gives a decent overview of some of the unique considerations of mobile development.

Tweet This Post

I am doing an independent study this semester regarding developing for mobile platforms. Mainly I am looking at the differences between conventional development, and mobile development. Since I have not been keeping up on my blog, this seemed a natural place to keep track of what I am learning. So here is the first ‘installment.’

*****************************

One primary concern when developing applications for mobile devices is hardware capability. In a desktop world, we are pretty used to throwing memory into a lagging system, so 4 Gigabytes is no longer unusual, and with 64 bit memory access, even 8 or 16 gigs is not too unusual. Mobile devices are (obviously) on the other end of the continuum. An HTC Fuze has 288 Megabytes of memory. A 3rd generation iPod Touch has 256 Megabytes of memory. A BlackBerry Bold only has 128 Megs of memory.

Then there are processor limitations. My Zune HD uses an Nvidia Tegra processor, which can run up to 800Mhz. The Blackberry 9600 uses an Intel XScale 624 MHz CPU. Mobile device manufacturers overcome these limitations by using muilt-core processors. The Tegra processor has 8 specialized cores; one for audio, one for display, one for HD images, etc. Most other mobile devices that I researched used dual core processors, and run in the 600 Mhz range.

Additionally, storage space is limited. While my Zune has 32 gigs of storage, my Fuze only has 512 Megs total.

I came up with a couple of considerations:

• Are you going to develop for a single platform, or multiple platforms?
• Are you going to develop for a single device, or multiple devices?
• Are you going to make use of built-in hardware like accelerometers or touch screens?
• Are you going to only support newer devices?
• Is the application going to be web based or stand-alone?

Single or Multi-Platform

From the perspective of wanting to reach as large an audience as possible, it makes sense to want to develop for multiple platforms. However, then one has to consider whether or not one wants to use a cross-platform compatible language like Java, or develop strictly for a particular platform like Windows or Apple. There are a couple of things that come to mind. When I researched available languages that are considered cross-platform, some other issues appeared that I had not thought of. For instance, Java ME has issues with inconsistent JVMs and so has to be tweaked to counter device-specific issues. Other considerations are the functionality of the platform, and market penetration of the platform.

Single or Multiple devices

While we are talking about device-specific issues, it might be a good idea to at least touch on the idea that we need to consider the devices on which the application will be running. Unlike someone who develops for the desktop and doesn’t really have to be conscious of whether or not an app is going to run differently based on whether the machine is running an Intel processor or AMD processor. The best analogy that I can come up with is that in order to understand some of the possible issues, the desktop developer would have to consider how their application would run on a system using an ASUS motherboard vs a system using an EVGA motherboard.

Web based versus Stand-Alone

Initially, it would seem to me that the most reasonable way to reach the most people possible without the hassle of dealing with multiple devices and multiple platforms would be to simply make the application web based. It would also prevent your application from being pirated. It’s a win-win situation, right? Well, not exactly. The screen on my Fuze is 2.8" diagonally. That means that any unneeded elements are out. So perhaps I need my user to be able to move to move back and forth through a set of screens in more or less a linear fashion. I would have to add two buttons somewhere on the screen that represent forward and backward. Or, I could harness the accelerometers and simply have the user tip the device left to move backwards, or tip the device right to move forward. As far as I know, there is little support that will allow web based applications to natively interact with a device. Another consideration is whether or not my application needs to write to the file system.

Device Specific Interactions

One of the nice things about accelerometers is that one can use them to detect which way the device is oriented and automatically scale the application based on whether or not it was being viewed in landscape mode or portrait mode. As a developer, I am always eager to try out the latest and greatest, but if we stop to consider how an application may be used, we may reconsider how we use the capabilities of the device. For instance, on a bus ride across town, it is not at all unusual to be bounced around. Too much bouncing, and the application may react in ways that the user does not expect.

The other problem with writing to the capabilities of a specific device is that they are not necessarily standardized across devices, and people will get confused if an application works one way on a particular device, but a different way on another device. Actually, that’s two things, but they are sort of related.

Old VS New

I have read a couple of papers that seem to indicate that people less frequently update their mobile computing devices when compared to laptops and desktop systems, but I am not sure that I am ready to buy into that idea at all. From a developers standpoint, I agree that I frequently upgrade my systems in order to remain productive, but most people are not developers. Second, compared to a good laptop (Netbooks excluded), a new phone costs substantially less. That raises an interesting question that I am not sure there is a good answer for. Do I worry about developing for older devices, or do I consider that most of them will be obsolete in two years and not worry about it?

Some interesting links:

Here are a couple of Wikipedia pages that I thought were sort of interesting:

http://en.wikipedia.org/wiki/Multiple_phone_web_based_application_framework

http://en.wikipedia.org/wiki/Mobile_development

Tweet This Post

The UPS man just showed up with my new netbook, courtesy of Asus and the Microsoft Student Partners Program. The only difference between this one and the listed specs is that this one came with Windows 7 Ultimate preinstalled. Suhweet! It also came with a brand-spankin new Targus backpack.

Tweet This Post

I’m not calling this a party, especially after seeing the really cool Windows 7 parties on YouTube. We all know that which has been seen can never be unseen.

Tweet This Post