My thoughts about the Verizon iPhone

AT&T exclusivity is over and Verizon wireless will finally start selling iPhone to their users. So should you jump the bandwagon and switch to Verizon next month? Here's some things to think about.

• Verizon iPhone won't be able to use data while taking a call. Verizon's current 3G network does not support this feature. AT&T does.
• Verizon iPhone's antenna has been revised and moved the volume rocker and mute switch down. This means that if you are switching from an AT&T iPhone 4, you will have to buy a new case for it.
• Verizon iPhone won't be using their 4G LTE network. What does this mean? Verizon's 4G LTE will be using sim cards like AT&T and T-Mobile. This enables their users to switch phones by swapping sim cards. Verizon's iPhone is stuck with CMDA technology. CDMA = no sim card. So why would you want to be stuck with 3G CMDA when they are rolling out 4G devices?

So if you ask me if you should get the iPhone now, I'd say wait till they roll out one that supports their 4G networks. But if you really can't then by all means go ahead and buy it :D.

The Process of Interaction Design

In my last blog, I was talking about Chapter 7 my Interaction Design textbook which covered the different methods of data gathering. The next three chapters dealt with data analysis, the process of interaction design, and identifying requirements.

In data gathering, data can be broken down into two different categories, qualitative and quantitative. Both types of data can be analyzed differently. Researchers try to find patterns and trends to support their theories and findings. Graphical representation of data helps in identifying patterns easily in quantitative data. Grounded theory, activity theory, and distributed cognition was used by the author of the textbook to analyze qualitative data. These frameworks work by breaking down the qualitative data into smaller and smaller categories so that they can find the trend or patterns at the refined categories.

The next chapter focused on the early stages of interaction design. The planning of interaction design from identifying the needs all the way to implementing the requirements. This chapter emphasized on catering to the user. As a developer, I believe that it's important to base my work upon the user's requirements and request rather than trying to do it my way. This ensures that the user will be happy with the final product. Involving the user during the process is also key to achieving better product. Letting the user play with the prototype let's the designer know what works and what needs to be refined. Different lifecycle models were also explained in this chapter. In my experience, we used Agile development in my software engineering class. Agile development focused on collaboration and that is exactly how we developed for my previous course. Letting you peers do constructive criticism of your code helps you develop and mature as a developer.

Chapter 10 was pretty simple. It uses the previous lectures from data gathering and analysis to identify and establish requirements. Nothing much to talk about since it just talked about how to apply the previous methods.

Next time I hope to find a journal from the ACM library that interests me. I'm currently looking at the latest journals that relates to Android.

Interaction Design

It's been a crazy past two weeks with all the midterms, career fairs, and job interviews. I've been slowly catching up with the readings for my HCI class. Last time we met, Prof. Robertson assigned me a new book to read called Interaction Design: Beyond Human-Computer Interaction.

The book starts out with some basic intro about interaction design. Comparing good and poorly designed products such as voicemail systems and remote controls. I noticed that these books likes to pick on telephone/voicemail as an example of poorly designed products. It's also interesting that in today's world, we still continue to use those poorly designed products. The book defined interaction design as "designing products to support the way people communicate and interact in their everyday and working lives." I understand that interaction design is the bigger picture and HCI is just one aspect of it. There are many different types of discipline that's involved in interaction design. The book explained some of the benefits and negatives of this. The biggest pro of having people from different disciplines and backgrounds come together is the creation of more ideas coming from different perspectives. This could lead to more creativity. This however is also the biggest con. The clashing of different ideas could lead to conflicts and confusion. Some prefer to do it a certain way while others have their own ways of doing things. The book also mentioned the different usability goals and use experience goals that we have to think about while in the process of interaction design. The text also used the design principles that I read from Donald Norman.

In order to create good designed products, designers has to do some research on the consumers. Chapter 7 of the text covered the different ways of gathering data. Data recording, interviews, surveys/questionnaires, and observations are some of the main ways to gather data.

I have a lot more to read so more to come later.

Everything starts with design

This semester, I am taking a course about Human Computer Interaction (HCI). I had no idea what to expect coming in to this class. I thought it would just be about how humans interact with computers. As the semester went along, I slowly realized that this course revolves more around the concept of design. The way we interact with everyday items depend on how good or bad it is designed. The main text that I'm reading for this course is called The Design of Everyday Things by Donald A. Norman. I'm not much of a reader but this book is pretty interesting. The book is outdated but the examples that he provides while explaining the concepts are clear and that makes things easier to understand.

Each chapter begins with a real life situation. I really like this way of organizing the text because it's easier for me to understand the concepts. The main principles in terms of design that I got from the first chapter are visibility, mapping, and feedback.

Visibility basically is the labeling part of design. An everyday example of this is a computer keyboard. Each key is labeled appropriately so that it's visible for us users. For users that aren't too familiar with the keyboard layout, visibility enables them to use knowledge that's available in the outside world. So instead of them trying to remember what key corresponds to to what, the label on the keys will give this information thus reducing stress inflicted upon the user. In today's world, visibility is neglected in designing things to make way for "looks." Take mobile gadgets for example. Some buttons aren't marked at all so sometimes there's no way of telling what that button would do before pressing it.

We all know that pressing the power button turn on/off something, pressing the letter J on the keyboard inputs that same letter. We know this because those things are designed to map out with their respective outcome. Poor mapping occurs when a single thing is mapped out to do multiple things. Norman used the telephone as an example of bad mapping. One of the buttons on his telephone example is mapped out to hold, park, or transfer calls. His example wasn't labeled appropriately so bad visibility is shown. I believe that visibility and mapping goes hand in hand in the design process.

For a user to know if their action was taken, the designer needs to implement a feedback mechanism. Many smartphones in the market today are equipped with touch screens. Manufacturers enables haptic feedback so that the device vibrates when the user makes a selection. This example has a tradeoff in terms of battery life. Because UI navigation heavily relies on the user touching the screen, it means that the device is constantly vibrating which sucks a lot of battery life. I always turn this feature off because I rely more on visibility for feedback with my mobile device.

It clearly takes a lot of thought when designing not just software but anything in general. I think that catering the design according to the intended users are important rather than just doing whatever works for the designer. This is where research and studies come first to help with the design process. But no matter how well you design a product, users will always make an error. We are humans, no one is perfect. This is why the designer must also implement the appropriate responses when the user makes an error. A cool example of error detection/correction is the swype technology on android smartphones. This technology enables the user to swype around the software keyboard instead of the traditional tapping method. It's algorithm is smart enough to know the intended word that the user is trying to type. Basically you swype from letter to the next till the word is spelled. But what if the user uses shortcuts words that aren't in the dictionary? Swype is smart enough that it learns the user's custom words by typing it the normal way. Swype adds the new word to the library so that the user can just swype it next time. A lot of times, swyping a certain way can yield multiple result. Swype addresses this issue by having a pop up of words that matches that pattern. The user can quickly tap the intended word and continue swyping. This method makes user input much more efficient and even faster than using physical keyboard on mobile devices. I want to post example pictures of how this technology works but I can't find a way to take a snapshot while trying to swype at the same time. I'll update this post once I figure that out.

Finals week is just around the corner...

Finally made some progress this week after being stagnant for a while. We tried to tackle our database problem lately with a less efficient solution but it seems to be working so far. So far we only have one verification working (Text Input). Our goal is to make sure that one verification works perfectly so we can apply the same to the other two verification types. The following screenshot shows the text field when a user selects an activity.

This next image shows a list of available activities. It also displays a list of activities that the user participated with.

Lastly, this screenshot shows the backend side where the admin can view a list of user submitted activities for confirmation. This is where the admin can confirm or deny the submission.

We still have a long way to go but I know our group will pull through. Summer, are you here yet?

-David Joel Lazaro

Birthday Weekend Over :( back to work

Took a little break last week to celebrate my 23rd birth anniversary :D. Nothing really much to say about our project at the moment. Still working and getting stuff done slowly but surely.

One interesting thing that I started recently was my Android development. This is a side project that I've been meaning to do since it's free compared to Apple's $100 dev fee platform. I've set up a separate workspace in Eclipse for my Android apps. Right now I'm still in the learning phase. Still trying to familiarize myself with it. So far it's not too bad because I'm coding in Java. Here's a little screen shot of what I have so far:

I can almost see the finish line....

Wishes do come true! We get to stay in the same group and continue working on this project for the rest of the semester! Only couple weeks of school left and our group is planning on finishing strong. Our current status is still trying to catch up with the other CMS group. We might be a little behind schedule but I think that we are on the right direction and I'm confident that we can pull through.

Right now we are still trying to figure out how to approach the verification type aspect of our Joomla component. We have some ideas to implement so it's a work in progress. Not sure if I mentioned it before but there are three types of verification for this component. A text input, confirmation code, and an upload image form. The following image is the schema that we are currently working with.

This schema might change as we are constantly trying to improve our component. After we finish developing this component, we plan on publishing the final package so that the general public can download and install this on their own Joomla websites. With our DeveloperGuide, we hope that any developer can tweak it to achieve their own requirements. There's a lot of things to do so it's time to do work son!

-David Joel Lazaro