A company called SnapKeys is pitching its “keyless keyboard” system to mobile device and computer makers, reports Reuters. SnapKeys’ software makes use of four invisible keys, each of which holds 6 or 7 letters. Two keys are placed on either side of a device’s display. The are other keys dedicated to punctuation. SnapKeys uses predictive software in conjunction with the invisible keys to guess at what people are attempting to type. Right now, it says its technology is 92% accurate in English with a dictionary of about 100,000 words. To start, the letters will overlay the device’s display when typing, but SnapKeys believes that users will eventually learn which letters are on each of the four keys and can turn off the overlay. SnapKeys believes its technology allows for much faster text entry on devices that lack physical keyboards. “There is a fundamental problem in entering data on mobile devices,” SnapKeys Chief Executive Benjamin Ghassabian told Reuters in an interview. “Keyboards were meant for fixed devices, not mobile. And screens are not supposed to be your input device; they are supposed to be output.” Many of today’s smartphones are touch-based and include software keyboards that appear on the display for text entry. SnapKeys said it is working with Philips, which is making the required hardware, and is in talks to sign deals with mobile device makers.
Month: September 2010
Ubuntu 4GB Ram Limitation and Solution
I’ve total 8 GB RAM installed in my dual boot Ubuntu Linux 10.10 (32 bit) version, but free -m command only shows 3291 (3G) memory. How do I use 8GB RAM under Ubuntu Linux? I do need to install Physical Address Extension (PAE) aware kernel under 32 bit Ubuntu Linux. It is a feature of x86 and x86-64 processors that allows more than 4 Gigabytes of physical memory to be used in 32-bit systems.
Without PAE kernel, you should see something as follows:
$ free -m
Sample output:
total used free shared buffers cached Mem: 3291 801 2489 0 95 342 -/+ buffers/cache: 363 2927 Swap: 1906 0 1906
You have two options here as follows:
Option # 1: Use 64 bit Ubuntu Linux
64 bit Linux kernel will take care of 4G or more memory. Just grab latest 64 bit version and install it.
Option #2: Install PAE enabled kernel
Open terminal and type the following command:
$ sudo apt-get update
$ sudo sudo apt-get install linux-headers-server linux-image-server linux-server
Once kernel images installed, just reboot your workstation, type:
$ sudo reboot
After reboot, login into your system and type the following command to verify memory usage:
$ free -m
Sample output:
total used free shared buffers cached Mem: 8105 1292 6812 0 38 483 -/+ buffers/cache: 770 7334 Swap: 1906 0 1906
10 things that make software user-friendly
Original post at TechRepublic
A product that’s difficult to figure out, inefficient to use, or poorly supported is not going to win much of a user base. See whether you agree with these criteria for user-friendliness.
Lately, I have touched a nerve with a few TechRepublic readers regarding the issue of user-friendliness –specifically, user-friendliness surrounding the Linux operating system. Of course, this debate isn’t limited to Linux. User-friendliness can be applied to every operating system, end-user application, proprietary in-house application, and more.
But what makes an application user-friendly? Here are10 criteria by which you should be judging everything you roll out to your end users, as well as anything you might be using yourself.
Note: This article is also available as a PDF download.
1: Simple to install
This applies to everything from operating systems to browser plug-ins. Installation is the first point of contact for users, so it had better be a friendly process. Otherwise, they’re going to be jaded the second they begin using your tool. It doesn’t matter whether it’s an operating system or a single-client user application, the installation should be simple and well documented. The second the installation becomes complicated, users will bail and move on to something easier.
2: Easy to update
As with the installation, an application’s update process should be easy. If updates are complex, users will more than likely skip the process. This can often leave behind a trail of bad results, as many updates patch security holes, memory leaks, and other problems. Updates need to be simple enough to ensure that users continue to benefit from the hard work of the creators of the software. When users don’t update, thus exposing issues, the software becomes less and less reliable and secure (as well as missing out on new features).
3: Intuitive
Software is only as good as its GUI. If the GUI is not well thought out and well executed, people will have issues with using the product. A well-designed GUI can often overcome a less-than-friendly underlying structure (or poor coding). But don’t bank all your hope on a good GUI — the software still needs to work as expected!
4: Efficient
Not only should a piece of software work as expected, it should also be efficient. It should be optimized for specific architecture, it should have all memory leaks plugged, and it should work seamlessly with underlying structures and subsystems. From the users’ point of view, the software should be an efficient means to completing their jobs. Software should not get in the way of completing a task, nor should it set up any roadblocks for users. The efficiency of a piece of software is tied up with its intuitiveness. A good example is the change Microsoft made to the Office interface. Switching from the standard interface to the Ribbon interface caused end users to waste precious work time simply trying to figure out where features were located. This was an inefficient (and inefficiently executed) design choice.
5: Pleasant, easy-to-navigate GUI
You might be thinking, “The Microsoft Office Ribbon Interface is horribly NOT intuitive, but it certainly is pleasant looking.” However, the look and feel of a GUI is a slippery slope that designers tend to tumble down. When a designer opts to go with trends instead of what works, it makes for an unpleasant experience for the end user. Instead of going with trends, add your own take on what is proven. The tried-and-true drop-down menu design has worked for years but is long overdue for an update — but this update should not come at the expense of intuitiveness. A GUI’s primary purpose is to make an end user’s job easier… and little more. If that can be achieved with an edgier design, go for it. But if your edgy design is counterintuitive and inefficient, it fails the user-friendliness test.
6: Easy to remove
Along with being easy to install and use, a piece of software should be easy to remove. Without a simple removal process, that software becomes cumbersome. And cumbersome is not user-friendly. As much as developers don’t want their users to remove their software, the removal process might be the last impression your software makes. Don’t make that impression a negative one.
7: Doesn’t need third-party software
One of my biggest problems with the Windows operating system is that more often than not, it requires third-party software to keep it running. This third-party software comes in the form of antivirus, anti-spyware, and other protection-based tools. Without these tools, your computer is vulnerable to whatever the malevolent powers that be want to throw at you. This is not user-friendly, as it creates levels of complication that most average end users can’t deal with.
8: Easy to troubleshoot
No software is perfect. And when something goes wrong with a piece of software, it’s important that the end user can call support and that support can resolve the issue. If the software offers nothing in the way of troubleshooting, how is the end user or the administrator going to be able to keep the software running? Windows 7 attempts to help the user out when a program crashes and does a fairly good job with it. In Linux, if you have problems with an application, you can always run it from the command line to see some of the issues presented. There are also third-party tools that can be used. But again, depending upon a third-party debugging tool is not user-friendly.
9: Adheres to standards
Standards are created for a reason — to make interconnectivity between applications or hardware easy. Problems begin to arise when developers do not adhere to standards. This has never been so obvious than with Microsoft Office. Microsoft has practically shunned the world of universal standards in favor of its own standards. This causes issues with other applications communicating with its software. OpenOffice is one office suite that does follow standards, but it often suffers because Microsoft doesn’t comply with standards set by governing bodies. When users are affected by a lack of compliance to standards, they’ll face an unfriendly experience trying to get their tools to communicate with tools that do follow standards.
10: Effective error handling
What happens when a piece of software encounters an error? Does it just go away without warning? Does it try to rectify the issue? Does it simply time out and then go on about its business? When a program comes across an error, it should make the error known, at least to the developers. It’s not the end users’ responsibility to report bugs, but giving them the option to report bugs can go a long way toward helping that software improve. When a program runs into an error and simply bails without warning or recourse, users are left with their eyes bugged out and their hands in the air. At least let users know there was a problem and what they can do to help solve it — such as sending a bug report to the developers.
How do you define user friendly?
Do these criteria fulfill your idea of what makes for a user-friendly software experience? If not, what would you remove or add to this list? Share your thoughts with your fellow TechRepublic readers.
10 Suggestions for the Architect of an Agile Team
Tom Hollander, a Solutions Architect at Microsoft Australia, held a presentation entitled The Role of an Architect in an Agile Team at TechEd Australia where he discussed what he does as an architect leading an agile team.
When talking about the role of an architect, Hollander means a “solution architect’ or an application architect. He does not refer to an enterprise architect or a specialist one (specialized on a specific field like messaging or infrastructure).
Hollander’s team has a 4 week iteration process with a stabilization period – code freeze for a few days – at the end, practices daily stand-up meetings, continuous integrations with daily builds followed by automated tests, and is employing a number of roles:
- PjM – is the Project Manager, similar to a Scrum Master, making sure the team is following the process.
- PdM – is the Product Manager, also known as the Customer or the Product Owner, determining what the product is supposed to be
- Architect – a solution/application architect
- Dev – the development team
- Test – the test team
- UX – the User Experience team
- Release – the Build and Release role taking care of the building process
Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team:
- “Just enough” upfront design – except for very simple projects, a certain amount of upfront design – 1-2 weeks – is absolutely needed based on what type of application is – web app, smart client, mobile or batch –, what are the basic functionality requirements, a long term solution or an intermediary, temporary one. The purpose of the upfront design is to decide: what technology to use – for example, ASP.NET or MVC –, what type of application – a 2-tier, a 3-tier or a service-oriented application –, accessing the DB – stored procedures, Entity Framework, LINQ, DI. All that can be contained in a short document for reference.
- Start with a vertical slice – means starting with a small piece of functionality – a logon page, for example – which cuts as many vertical layers as possible in order to tie together all the technology pieces decided during the previous phase. This will demonstrate that the design decisions are correct and all pieces are working together, and will represent a pattern for developers to follow when developing the additional code. If the initial design decisions turn out to be inappropriate, now it is a good time to change them.
- Just-in-time design each iteration – At the middle of a 4-week iteration, the project manager, the product manager and the architect should meet to discuss the requirements to be addressed during the following iteration, to make sure they all agree on them, what is more important is put up in front, and everything is understood. That discussion goes on for a week in the background of the current iteration. The following week, the last of the current iteration, the architect reviews the requirements for the next iteration, making the necessary design decisions so the team can start working on them the following week. If the requirements are quite different from previous ones, then the architect does some prototyping, writing some code as a proof of concept, writing some diagrams and putting it all together in a 5-page document for reference. This is not meant to do detailed design decisions made for the developer, but rather to make sure the new requirements fit into the big picture.
- Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for the team, solving difficult problems that might bog down the developers. The architect should be in contact with every developer each day, knowing what they are doing and helping them if there is a coding problem. This is especially needed when dealing with developers that don’t like to ask for help and try to solve problems on their own with the price of spending an entire week with that. This kind of relationship also applies to the PjM and test/build/release team.
- Write code! – The architect should know what’s in the code in order to have a better idea on the impact of his decisions. He can also figure out when a refactoring is needed. A code writing architect has better credibility with the development team. That being said, Hollander does not believe in role dissolution. He still thinks an architect remains an architect, and he’s not necessarily as good at writing code as a regular developer.
- Be involved in everything – It is good for the architect to be involved in all meetings related to his project: design, development, code reviews, requirements planning, etc., because he can have a larger and more clear perspective on what is going on, and he can help the product manager to avoid making wrong decisions in an early stage by informing him/her on their possible outcome.
- Drive a culture of quality – A successful team, one that anyone would like to be part of is one built on a culture of quality: nobody cuts corners, nobody checks-in sloppy code, if there is a major flaw in the design it won’t pass unnoticed, all are honest and open, looking for the best outcome of the entire team. Hollander admits that it is hard to build such a team, but it is possible. Firstly, the architect should establish some rules in the beginning, rules are are not going to change over time because a developer happens to not like them. One example is the decision to write unit tests. Another is having a code review before each check-in, including the code submitted by the architect. If the code is not accepted by the reviewer, which can be anybody in the team, the code is not checked-in.
- Know when changes are required – The architect should be very flexible and ready to make design changes when they are required. It may be that an early solution is no longer appropriate, or new requirements demand a different approach.
- Shield the team from external randomization – While this is usually the job of a project manager/Scrum master, the architect can get involved in protecting the team from external requests that tend to divert the team’s focus and take time from actual work. One example could be various requests coming from the operations team wanting certain things to be done in a certain way, and their requests are not always reasonable or something that has to be implemented.
- Write docs … but only if someone needs to read them – Hollander is not the adept of documenting everything, nor one of writing no documentation. He thinks there is necessary to have a balance, writing the amount of documentation that is actually helpful and is read by someone. Documents are good to remember detailed design decisions like a data model. Iteration design decisions, while they are discussed with the team at the beginning of the iteration, it is recommended to be saved in a 5-pages document for the developers to go to if one of them does not remember what the architect said. This also helps new people working on the project long after the initial developers and architect moved to another project to understand why some of the decisions were made.
As a conclusion, Hollander said the architect should make sure he is part of the team in theory and in practice. The architect is not supposed to write all the code, only a small portion, he is not testing or deploying it, but he is rather making sure the entire process runs smoothly.
How Ubuntu is Made
Sean Michael Kerner writes – Recent years have seen the Ubuntu Linux
distribution, led by Canonical, experiencing rapid growth in both
users and features. With the upcoming Ubuntu 10.10 Maverick Meerkat
release, set for October, Ubuntu developers will continue to push the
boundaries further of both server and desktop Linux. Sitting at the
upper rung of Ubuntu’s engineering efforts is Matt Zimmerman,
Canonical’s CTO, who helps to lead Ubuntu’s technical direction.