If you are a Human Being, then you might be interested to read the Fridge, and if you do then do not forget to check the news.
Clue?? Indian team goes into the Fridge and roxxx!! Thanks to Sayak B for authoring the article and congratulations for becoming a Fridge editor.
Following my earlier post on Ubuntu’s upcoming release Intrepid Ibex 8.10, and having seen a few people on Planet Ubuntu and my very own buddy tuxmaniac, I thought of posting how good and bad ibex seems to be at datetime.now().
If you’re installing or upgrading ibex at this instant, you might end up facing a few issues that seems to exist commonly. We hope you really understand that you’re installing a beta version, which is exclusively for people who want to play with a clay horse which hasn’t yet hardened up enough for the big fat kid to ride. You may catchup with one of the following,
Still, it is under progress and hope it would get fixed soon.Now, if you are past these things, welcome to the wonderful world of Intrepid Ibex. Things that have improved,
On the whole, this beta is a lot better than the beta(s) I have had so far from Ubuntu. When the final release happens, it’s gonna rock the world again and we’re working hard to make sure of it.
* 20 days more *
It’s just around the corner, your long trust worthy friend is taking a yet another avatar and arriving at your desktops soon. To celebrate 4 years of successful presence in your desktops, here comes another new release from the Ubuntu community, the Ubuntu 8.10 Intrepid Ibex. The brave wild goat is on the run towards your home and should land in your doorsteps by this moth end, ending 6 months of hard work that the wonderful Ubuntu community has put into it. The countdown has started… 24 days to go!
As a closest chance to taste it before it arrives, Ubuntu 8.10 Beta is now available for download. Get a copy and try it out. This can be another chance to contribute something back to your favourite Linux distribution, give us the feedback, test it out on your computers and report problems to us (ya, it’s beta and there can be issues here and there).
There are a few new things in Intrepid that are worth their mention…
Xorg 7.4 brings improved support for automatic configuration of input hardware, such as keyboards and mice. 3G support: Network Manager 0.7 comes with a number of greatly anticipated features, including management of 3G connections (GSM/CDMA) and PPP/PPPoE connnections. Guest sessions: the User Switcher panel applet provides a new option for starting a Guest session. This creates a temporary, password-less user account with restricted privileges - perfect for lending out your laptop for a quick email check.
If you belong to an official Ubuntu Loco Team, then you can pre-order Ubuntu Intrepid CDs even before it gets released and it will land at your doorstep within 2 weeks from the release date.
**Ubuntu India Team is not pre-ordering the Ubuntu Intrepid CDs because of the customs cost involved and to avoid the wastage of CDs it results in usually. We are otherwise pleased to burn you a copy of Intrepid given an empty media.
** Errr, that countdown banner javascript doesn’t seem to work with this blog. If I copy paste the<script> tag line, it just vanishes away when I save the page. *sigh*
When people speak about successful Open Source projects, what tops the list is the famous Open Source browser that’s been used by people not only on GNU/Linux, but on Windows and Mac as well. Firefox has always been the one prime example that OSS projects can be successful and famous. But no project is without problems, especially when the number of people using it and thereby the expectations on it from different kinds of people keeps growing.
This is not the first time that a GNU/Linux distribution is facing a problem with people behind the brand Firefox, indeed many distros took the decision to denounce the brand name Firefox and stay as Free as possible. But there were other distros which managed to get into an understanding and could keep the Firefox ball rolling.
What has happened over the recent past is that Firefox has come up with a requirement that when the distribution makes it’s own changes to Firefox and still want to use the branding of Firefox have to display an EULA when it’s users start Firefox the first time. As the distro chose to bundle Firefox as the default browser, this means that when you install this distro and start the browser the very first time, you have to face an EULA and agree to it to continue using the browser.
The second wave of problem associated with this is that it is conspired that the distro chose to implement this without consulting, debating and discussing with the community. A recent thread started in its bug tracker, lead to a long discussion (which many felt should have happened in a mailing list and not in a bug tracker).
The possible outcomes can be,
A lot of people support solution #3, especially those who want Ubuntu to strongly adhere to being like a Free Software distribution. My knowledge is very limited to the legal fundas behind it, but lots of people like me are also concerned. At one side, it’s about the philosophy of freedom which had been keeping us with FOSS. On the other side, it might be losing a well matured and powerful browser like Firefox. But we all hope that the final decision taken by people behind Ubuntu will be to the best interests of its community and something a major portion of the community can accept.
Am either lazy or find no time to sit and craft a blog post. Anyways, need to catch up with things once in a while and keep this blog alive.
Ubuntu Developer Week happened between September 1-5 2008 at #ubuntu-classroom in irc.feenode.net. It was very informative and useful, introducing to a wide variety of topics from bugs to patches to coding to testing. I managed to catch up with a few of them, even tried to try it hands on during the session. It was one smilar session that I got used to bug triaging months ago, and this time it was Daniel Holbach blessing me with more gyan about patching and packaging. There were other wonderful sessions on Upstream Bug Linkages by Jorge Castro, a WebKit browser in PyKDE by Riddel, Unit Testing Python code by Lars Wirzenius, Introduction to Bzr by David Futcher, and a lot more. I plan to convert these logs into properly formatted documents and load them to the ubuntu-in wiki. The participation in most of these sessions were awesome, with the opening session by Holback drawing around 200 people to be on the channel. Discovered a lot more ways to contribute to Ubuntu and need to work a lot more on it in coming days.
My dear buddy from ILUGC Aanjhan Ranganathan aka tuxmaniac left India and has safely landed in Swiss soil, even settled down in his accommodation. Will be missing him a lot although he is always present in oru channel #ubuntu-in. He is the one who always gives me lift in his car whenever we both were in Chennai and could attend ILUGC meet. Best wishes to him, as this is one of his long existent dreams which has started happening 
Watched my much awaited KDE Usability Project talk by Celeste during Akademy 2008. Videos for talks from Akademy 2008 are starting to appear and the here mentioned talk can be got as OGG video from here. Looking forward for the video taken during the Usability workshop conducted during Akademy 2008 as well.
That’s it for now, catch you all soon..
My weekends have either become boring with housekeeping chores or traveling to villages meeting my relatives. But this one was different, with 4 of my Ubuntu Indian Team buddies turning up at my house for almost half a day. Aanjhan (tuxmanaic), Onkar Shinde (slytherin) and Roshan (ubunturos) made it to my home by 1 PM, soon followed by Barkha (baks17) who managed to come close to my house and then lost the way. It was a farewell meet for 2 of them and welcome (to Bengaluru) meet for another one (I leave it as homework for you to find who is who )
Then as all of us were quite hungry, we made a little walk to Nandini at R T Nagar and managed to get a table for 5 within 5 minutes. The poor thing was all of us were vegetarians 
and hence we ended up ordering Andhra Full Meals for 3 of us while the other 2 resorted to Naans and Rotis. The food was very good and we were half asleep when we came out of the restaurant. Onkar then picked up some sweet corn on the way. We came back home and starting preparing for the hackathon/bug jam. Aanjhan and I managed to fix my router to work without fiddling with my modem and thereby all the laptops got some wireless internet.
Aanjhan and Onkar started working on some GNUSim8085 stuff while I was trying to hunt some bugs. Barkha was busy buying train tickets for her trip tomorrow to Chennai. There was some fun with Barkha booking wrong train and getting confused with her plans. It was followed by much funnier “Install Linux without messing my Vista” adventure, with Fedora not having a back button during the installation process and hence we succeeding in making Barkha resort back to Ubuntu. As she wanted to shrink a NTFS partition, we decided to give her the helping hands of GParted, but as the partition was too big to be shrunk to half its size it took tooo long that it didn’t even finish when she left my home in the night.
In the mean time, Barkha got some milk (and some biscuits which nobody ate) and everygot got some hot cup of Bru coffee Also, thanks to Barkha for the sweets which she got from Mumbai
All together it was fun with 5 Ubunteros meeting on a Sunday and after a long time I had some visitors at my home I won’t be meeting Aanjhan and Barkha for <unknown-value> months as they are both flying out of the country. Looking forward to one such meet sometime someday
On a wonderful August weekend, passionate men and women joined together as partners in crime of killing bugs and helping a wonderful Linux distribution get better. Though crimes are generally considered against humanity, this was indeed motivated by humanity and helping humans with better software to use on their computers. If you haven’t heard it before, I would like to update your database made of neurons and electrolytes packed safely within your skull that there was a worldwide effort to kill a 1000 bugs that was reported in Launchpad by it’s wonderful users for various software and components of Ubuntu.
The wonderful part of an Open Source community is that you are free to complain when you find something not working the way you want. The more important part is that your complaints are rather considered as contributions and hence welcomed with a big smile. Secondly, your complaints are attended by a wonderful team of people, who call themselves members of the bug squad, that it doesn’t go unheard, into dark matter. They help you to provide more information about your problem that it makes sense to the developers, who can then work on solving your problem and release them in the next update for the software. These people are those who put themselves as a bridge between users and developers, helping both the sides to help one another.
Though bug squad been working day and night for a long time, we are still an under-powered team when you consider the amount of bugs people are able to find in software. Also, we there will be times when the user thinks differently from what the developer expected him to be thinking, resulting in a misunderstanding of a feature or lack of one as a bug. These things need to be sorted out too. The team has also been trying to motivate a lot of users and passionate contributors to join the bug squad and help them make Ubuntu better. As an opportunity to show case this, we decided to go for a global display of bug squashing. Thanks to Daniel Holbach and his wonderful idea of Global Bug Jam, we are satisfied that we did a good job.
With loco teams participating from around the world, including the Indian team, the mega event took place during this weekend. As every hours passed more and more bugs we getting squashed, and more bugs were moving towards an improved state that they could be killed someday completely.
Let me stop my story telling and fill you up with some facts to prove how effective it was. First check this out to know where we stand at the end of GBJ August 2008.
Global Bug Jam Meter
Now to know more statistics about the bug jam and how each triager and team performed, check out the stats at 5-a-day stats page
Hope you got an Idea of the effort that the Ubuntu community has put in to make the lives of Ubuntu users better by making Ubuntu better. Thanks to all fellow GBJ participants, my fellow bug squad members, my loving Indian team members and all users who filed those bugs. We have made a conscious effort to improve things, and we will continue to strive make Ubuntu better, and ahem.. may be kill bug #1 someday
The post will remain incomplete without talking about the dark side, not about the GBJ itself but about the extent of participation from the Indian team. As tuxmaniac had already blogged about it, I will just put things in my own simple way,
) and finally it’s a window to move to next level and get into the community.In addition, almost at the end of the GBJ, we had a long time user complaining that one of the triagers who commented on his 2 year old bug wasn’t polite enough. We had a long discussion following it, concluding that the Bug Triage HowTo documents should stress more on being polite to bug reporters, whatever the circumstances be. Even if the bug sounds of no meaning, even if it’s not a bug at all, we need to be polite and explanatory on why we are taking a specific stance on the bug. There is something to learn at our every effort, and we learnt one this time for sure. Now it depends on how it gets moved on and implemented.
I would hereby wind up this report on Global Bug Jam August 2008. If you missed it this time don’t worry, dholbach is conspiring about another one soon. Don’t think twice to join us, and though these are wonderful opportunities to break your shell and contribute, you are always welcomed to poke us any time to know how you can help us. Never think twice to bug me on these matters
Waiting for the next Bug Jam..
நான் தமிழில் எழுதுகின்றேன், நீங்கள் தமிழில் இதை படிக்கின்றீர்கள் என்றும் நம்புகின்றேன். ஆனால் என்னைபோல உங்களால் தமிழில் எழுத முடிகிறதா? இல்லை என்றால் பிழை இல்லை, ஆனால் எழுத என்றாவது முயற்சித்திருக்கின்றீர்களா? சில மாதங்களுக்கு முன்புவரை இது கொஞ்சம் கடிணமான காரியமாகத்தான் இருந்தது. ஆனால், hardy heronஇல் இம்முறையானது மிகவும் எளிதாக்கப்பட்டுவிட்டது. எப்படியென்று இதோ விளக்குகின்றேன்,
1. System > Administration > Language Supportஐ திறக்கவும்
2. இதில் எல்லா மொழிகளும் வரிசையாக தொகுக்கப்பட்டுயிருக்கும். இதில் “Tamil”ஐ தேர்வு செய்யவும். தேர்வு செய்யப்பட்டுள்ள மொழிகளின் அருகிலுள்ள சதுரத்தில் ஒரு tick குரியை கானலாம்.
3. ஒரு புதிய மொழியை தேர்வு செய்யும்பொழுது அதற்கு தேவையான சில language packagesகள் நிருவ வேண்டியிருக்கும். Install ஆகாத மொழிகளை தேர்வு செய்ய்தால் Ubuntu தானாக அதை install செய்ய உங்களின் அனுமதியை நாடும். Internet connection இருக்குமாயில் அந்த packageகளை உங்களால் நிருவிக்கொள்ளலாம்.
4. இந்த packageகளை நிருவியபின்னர், System > Preferences > SCIM Input Method Setupஐ திறக்கவும். இதில் நாம் SCIMஐ உபயோகப்ப்டுத்தும் முறையை configure செய்ய இயலும். அடிப்படையாம் நாம் SCIMஐ trigger on மற்றும் off செய்யும் முறையை நாம் குறிப்பிட வேண்டும். பொதுவாக இதை CTRL+Space அல்லது CTRL+ALT+Space ஐ பயன்பத்துவது வழக்கம்.
5. கடைசியாக நாம் செய்யவேண்டியது ஒன்றேயொன்றுதான். Logout செய்து மீண்டும் login செய்யுங்கள்.
6. இப்பொழுது நீங்கள் முன்பு குறிப்பிட்ட trigger key combinationஐ (அதாவது CTRL+Spaceஐ போன்று நீங்கள் தேர்வு செய்தது) செயல்படுத்திப்பாருங்கள். ஒரு குட்டி popup உங்கள் முன்னால் தெரியும். இதில் நீங்கள் உபயோகப்படுத்த விரும்பும் மொழியை தேர்ந்தெடுக்கலாம். ஒன்றை மற்றும் நினைவில் வைத்துக்கொள்ளுங்கள், நீங்கள் SCIMஐ செயல்படுத்தும் சமையத்தில் cursor மற்றும் focus ஆனது text input செய்யகூடிய text input field ஒன்றில் இருக்கவேண்டும். இல்லையென்றால் SCIM ஆனது இருந்தும் இல்லாத்து போன்றுதான் இருக்கும்.
இன்னும் ஒரு இலவச குறிப்பு: உங்களுக்கு தமிழ் typing தெரியவில்லை என்றால் கவலைப்பட வேண்டாம். தமிழ் மொழிக்கு SCIMஇல் phonetic keyboard input உள்ளது. இதைக்கொண்டு ஆங்கிலத்தில் தமிழ் வார்த்தைகளை எழுத, அவை தமிழ் வார்தைகளாக தெரியும்.
மேல் கூரியவற்றை பின்பற்றுவதில் எதேனும் சந்தேகம் இருந்தால், யோசிக்காமல் இந்த blog postஇலேயே commentஆக எழுதவும்.
I have been always wanting to contribute to Ubuntu since the day I joined Ubuntu India Team. But, other things happening around me always kept me from converting this wish into action. It was this new year that I finally took a resolution to start some solid contribution to the Ubuntu project. The most viable options was to Ubuntu Bugs at Launchpad, which in better terms is the bug tracking system for Ubuntu.
The formal way to help with bugs (not formal as it literally means) is to join the bug squad, the team of ubunteros whose sole motive is to check bugs filed by the users, help the users provide as much information about their problem as possible, assign bugs to related packages, find earlier reports which is very similar or sometimes the same (duplicate bugs), assign status and importance for bugs and finally make it all ready for developers to work on them. This process also filters out reported bugs which are not bugs but user end mistakes, which are rather feature requests (wishlist) or merely misunderstood normal behaviors. In addition, we can also file patches for the bugs if we know how to fix them, which actually reduces a lot of developer time (which is precious).
So, where did I get started? Actually two places, one is Launchpad Bugs for Ubuntu and second is the bug squad team channel #ubuntu-bugs at irc.freenode.net. When I joined the team, the irc channel was both a place to discuss about bugs as well as where the bug announce bot was running, announcing the channel whenever a new bug was filed. Later, the bug announce was moved to #ubuuntu-bugs-announce channel, while #ubuntu-bugs became a complete discussion channel for the bug squad. Then I started reading the docs in the wiki, especially the following,
Apart from reading docs, I started observing how triagers respond to bugs. When I got an idea of the basics, I started triage with some newly filed bugs, easy ones which I could make sense of from the description. All I did was find bugs where I can ask for more information from the reporter. This is the easiest way to start as most filed bugs lack in one information or another, and it’s the primary task of the triager to get as much information from the reporters as possible.
Most people miss out the Ubuntu version they are reporting the bug against, the related package for which the bug is filed and it’s version. These are minimal information required in the bug report. The next important thing is how complete and meaningful is the bug description itself. It is not uncommon for people to be in a tensed mood when they file bugs and their description is quite unclear about their problem. Minimal requirements of a good description are what is their problem and how to reproduce this problem. Some reporters also specify things they tried to fix the problem, and surprisingly sometimes this ends to be round about solution for the problem. Some people take more responsibility of getting into the problem, finding a fix and submitting a patch to the bug as well (which is amazing btw). Now bug triage doesn’t seem to be simple all together, but it offers various levels of participation fitting with one’s level of interest and skills. I know of a few in bug squad who are specialist in dealing with duplicates, which is nothing but a reporter filing a bug which already someone (or even many others) have filed already.
Filing a same bug doesn’t help much, rather what would be welcome is looking at existing bug and adding additional information to it if possible. Similarly, one can also check existing bugs and if the problem can be reproduced at our end we can indeed confirm the bug reported by someone else.A bug also gets confirmed when the triager feels that the bug report enough information for the developer to deal with it. There is no hard and fast rule, but some guidelines on what makes a report complete (which you can find in link 1 above) and is often acquired as a trait by experience.
There is not much for the basic level of bug triage. As I got involved doing these basic things, I started learning more. Sometimes I have done little mistakes, but as I always refer to people in #ubuntu-bugs for doubt, my mistakes got immediately corrected. Am still in the lower levels of bug triage, but learning a lot. One wonderful endeavour regarding bug triage is 5-a-day project started by Daniel Holbach. It is nothing but a team of bug triagers who make sure they at least triage 5 bugs a day. This has really been working and if you would like to see some stats check this one out. One handy link for every new triager is the Checklist.
So, when can you join us? Anytime anyday and if you are looking for special time to join then Hug Day and Global Bug Jam could be a nice opportunity
I made it yesterday though it was late into the midnight, attending Kubuntu Tutorials Day at #kubuntu-devel. The session I was interested to catch up was the second one by Celeste Lyn Paul aka seele on Usability. I have heard about her, her work, KDE-HIG and openusability.org a few months ago after I attended the HCI workshop at IIT Bombay. The following are the brief notes from my scratch pad on what seele said during her session. Official logs from the Kubuntu Tutorials Day should be available soon (or am not yet aware of the link yet..) and will update when I get it.
( Questions from seele are in italics, with related links I managed to get by Googling and my own comments. A little bit of editing to make it look a bit “blog formal” and readable. Comments are welcome, especially if you find something wrong )
In 20 words or less, what do you guys think usability is? (and no cheating on wikipedia)
If we take this from an ISO standard, usability means that a product must be,
1.learnable
2. efficient
3. memorable
4. prevent errors, and
5. be satisfactory to users
Learnable
This is the one no one usually picks when i ask the “what is usability” question. A product (in our case software) doesn’t have to be so easy that you don’t have to learn it. For a simple task, then you expect it to be simple but for a complex task, it is OK to expect learning.
Efficiency
This probably shouldn’t be #2 even though it is listed in the ISO spec this way, because it is related to learnability and memorability. But it is exactly what the word means, an appropriate use of time and resources in relation to the complexity of the system. Even if you made a simple printing function an easy to use 10 step wizard, it isn’t very efficient if you need to do that every time you print. Clicking one button will get the same amount of work done than stepping the user through all the options and clicking 10.
Memorability
This is what I think should be #2 because it is closely related to learnability.
Have you guys ever heard of the term Information Scent? It is an Information Science Theory
Information scent is a search behavior theory. Information scientists believe we search using the “gathering” skills of our “hunter-gatherer” basic instincts. What it turns in to from a UI perspective is how easy it is to find information (functionality or options) from it’s surface presentation. So, what options you expect to be under menu X before you open menu X? By having good information scent (good labels, structure, etc.), you can use the UI more efficiently because you can stack layers of information.
Basically you are leaving hints to the user to find the information on their own, they don’t need to Remember where options are, but only follow a logical path. This saves the user’s cognitive resources to go on and solve more complex problems instead of using them on the UI. Remember that a UI is a tool to solve a problem, the UI shouldn’t be the problem.
Error Prevention
Have any of you guys heard of Jef Raskin?
He was a famous designer who worked at apple (i think he was employee #12 or something close). He was a true user advocate in the sense that he believed no matter what the circumstance, the computer should do no harm. Also, many of you are probably familiar with the practice of confirming actions, particularly destructive ones, yes? Error prevention is more than just confirming a destructive action. It is preventing the user from having to make that decision to start with.
We dont see this too much in the desktop environment because we model a lot of our work-flows off of existing software, but i see this a lot in other expert systems. “Are you really sure you want to do that? It will cripple the system and you will lose all of your data” (Well then, the user should have never been able to choose that option from the top level of a UI). Even so, there are a lot of confirmations we do in the desktop environment which could be prevented if we shaped the work-flow differently; the user should never have to select Cancel.
Satisfaction (keeping it consistent
Satisfaction is the quality many people tend to identify with usability. But it is also the last dimension in the spec (and i believe the least important of all we’ve talk about). Satisfaction is important. If a user finds a system pretty or cool, they will want to use it more than the other system that is not. Users will sacrifice ALL of the other parts of usability (learnability, efficiency, memorability, error prevention) for satisfaction. our goal is to help them not make sacrifices.
I’ve seen users in usability tests take 3, 4, 10 times longer to complete a task in a terrible UI that looked pretty, and complete the same task in a different not-as-pretty UI much much faster and they still like the pretty UI.This is an advantage and disadvantage: it gives us room to experiment because users will be forgiving if we give them options they want or other cool toys; but at the same time, we should use eye candy as a crutch to solve problems. We should solve problems and make our solutions beautiful.
Have you guys ever heard of a one-time learning event?
Often when you are reviewing a new UI or work-flow, one of the questions you may ask yourself is “will the user figure this out”; and the first time around, sometime the user doesn’t. they can’t find the options, they don’t know the label, they can’t figure it out. But,if they have someone show them how to do it, they find the solution on a webpage, or painfully figure it out, it makes sense to them and they remember it for next time. We call this type of experience a one time learning event
They won’t figure it out the first time, but if they can do it once, they will remember how to do it. This is something that is often forgotten in UI design. You can break users out in to different dimensions – one of them being problem solving skills and related motivation, some users are not afraid to try something and fail, other users will not try new things in fear of failing and the users who do not explore are at risk of never exploring options hidden behind a single-learning event.
That’s why doing user research on your product and understanding who your users are, their motivations, environment, and their skill (it’s not JUST about their skills) is important. This leads me in to a discussion about universal usability.
Has anyone heard this term “Universal Usability” before?
Universal Usability is the belief that any user, no matter their skill, background, motivation, experience, etc. should be able to pick up and use a product. In cases where products must serve the general public (such as e-voting machines), this could be a valid argument, but there are very few products that focus on EVERYONE. Even so, the concept of universal usability would be extremely difficult to achieve, especially in expert systems or systems which knowledge workers use
The ipod, why does everyone use that as an example of universal usability? The ipod is an excellent example of very sexy tech that people forgive its shortcomings for. It doesn’t do everything everyone wants, and not everyone can use it or figure it out, but because it is so damn beautiful, most people don’t care.
Universal usability forces designers to lower the bar of the average user to accommodate more people. This is why it hurts expert systems. If there is a pocket of experience or information that a certain group of users may not have or be able to attain, it must be removed.
[ To a question about apple and the point mentioned above...]
Yes, but apple traditionally does not follow a user-centered design approach. they believe that designers know better. It’s only been recently that they’ve done usability testing.. everything before was market research (which is very different).
[ We seemed to digress a bit, so I tried bringing it back on track with question ]
There are three domains of usability i work in: User Research, Design, and User Testing. Together, these are part of the user-centered design process (UCD). It is a design philosophy which keeps users in mind while creating a system for them.
User Research is often linked to the Requirements stage of software development. So when you developers are thinking of new features to integrate in to a software, or a new software to develop from scratch. Here are some things you should be thinking of in addition to your functionality spec and other things,
Who are your users?
Try to come up with some example users who you are building the software for. Even if you are a user, try to keep yourself out of the list, it makes it too easy to do what you want instead of what they need.
What will you users be doing too many times?
Not all of the functionality is documented or fully planned. A single function might be discussed and mapped, but the other functions of a system aren’t thought of until afterwards. What happens is you don’t have a complete picture of how your users are using the system, and if the functions are integrated properly mapping out screen flows before you begin coding will help document your functionality (so you aren’t trying to squeeze or force options in later) and give you a reference for when you code.
What problem are you trying to solve?
This is the big one, your Vision Statement. Having an idea of your goals before you start will help development. It is related to the “What are my users doing?” question. If you don’t know what problem you are trying to solve with your software, you can’t know what to provide users or what they will expect? Plus, in larger projects, it is a good idea that all the developers are on the same page. It prevents a lot of road map issues later on
Being able to answer those three questions will give you a head start. On KDE Techbase there are user research templates to help guide you.
I guess we will get in to Open Source Usability 101 now,
First step: Contact the project you want to work with and express interest in working with them.
You dont want to surprise developers by dropping a usability report in their inbox. It will just make them angry, even if the work was good.
Second step: Start small. Open source is a community based on commitment and trust (after the getting work done thing).
Start with a small activity such as interviewing users, conducting a survey, or doing a small UI review. This will help developers get used to your methods, get used to you, and know what to expect from your work.
Third step: Maintain your relationship with the project.
Design is an iterative process, just as open source is iterative development. Developers are wary of seagull designers: designers who fly in, poop on their software, then fly away. Developers are in for the long hull, they are committed to their project and want to see it succeed. They don’t want to work with a designer who will ask them to change a bunch of things, then disappear and not be able to comment on the results.
Obviously I don’t want to see any unhealthy marriages, but keep in mind that you will make a bigger difference in one project than doing a bunch of little activities for a bunch of projects. Design is a VERY iterative process; it is important for both you the designer and the developer you work with to understand this.
[ To my question whether we have something similar like KDE-HIG in Ubuntu/Kubuntu to which we can contribute.. ]
For Ubuntu designers, you will want to look at the GNOME HIG. It might be a little out of date, but one way to get started with contributing would be updating it!
For Kubuntu designers, you will want to look at the KDE4 HIG and the KDE3 User Interface Guidelines.
These are under active development, and so if you have any questions it would be best to ask me or Ellen Reitmayr who sometimes lurks in #openusability.
Other Resources:
Look at other interfaces that do similar things, not just in your own environment but in windows, KDE/GNOME, Mac OSX. You’ll find similar and very different solutions. You will want to look closely at the context of the solutions and make sure it is a good fit before you use it as a mode. Copying a solution will not solve a problem, the goal of reviewing other software is to get inspiration when you have no other better ideas.
[ The End - Applauds!! ]
Heard about this wonderful little GNOME app called Tasque from nixternal’s blog post today, checked it out (mean the web site) and found it useful. May be I will try it out soon, not now because I am not having much tasks to do and whatever I have is reminded by ReminderFox in ThunderBird. Good thing is it is available for both Hardy and Gutsy (thanks to nixternal) from tasque-packagers’ PPA.
While reading the latest issue of Full Circle Magazine today, I came across the Game section and was surprised to know Maryo was available in the Ubuntu Universe repository. The package is named smc, short form of Secret Maryo Chronicles. I downloaded it (some 41MB totally) and went running it. Unfortunately, it doesn’t get added in the menu. So I had to manually add it and also set its icon.
Always I have the habit of running a newly installed software from the terminal to check whether it spews some error or not. So did smc, there was some dependency error confirming to this launchpad bug. Luckily some one had prescribed a fix that makes it work. Had some fun playing Maryo after a long time. Hope they fix the bugs and we get a really super Maryo game in Hardy.
What is 5-A-Day? We, that means everybody, will do 5 bugs a day - every day. With only five bugs that everybody looks at every day, we will cover a lot of ground. What you can do? That's up to you, your interests and your abilities. - If you're a developer, you can help out reviewing patches and getting them uploaded. - If you want to just confirm new bugs, you can do that. - If you have experience with a certain package and want to triage bugs you can do that and forward them upstream if necessary. - If you know your way around Ubuntu quite well, you can help assign bugs to the right package. What you need to do to participate? - Do it! Follow the instructions on the 5-A-Day homepage - Spread the word by adding your 5 a day to your mailing list posts I have been trying my best to triage 5 bugs a day, but max I could do was 3. Hope I can try better in future.
Erased previous installation and installed Ubuntu 7.10 afresh. When I tried to check the blog stats in wordpress.com, which uses Flash for the chart, it gave me a missing plugin error. It also showed me a little pop up to install the plugin, but unfortunately it did not work. So I decided to try the alternative Gnash plugin, but it too didn’t seem to work.
A bit of googling took me to some Ubuntu Help Forum post where it was advised to get the Flash Player from the Adobe site and install it. This involves downloading the tar.gz file, extracting it out and running the flashplayer-installation script which installs the player. But this is to be done in the command line, followed by answering some simple questions. It asks to specify where the mozilla plugin directory is, which is /usr/lib/mozilla (and the plugin directory within), but this step kept failing.
This is where the hacker jumped out of me and made me to look into the source code of flashplayer-installation script to find out where it was going wrong and what I rather need to do to install. This script is accompanied by the actual plugin file `libflashplayer.so`. The scripts just performs some checks and copies this file to the mozilla plugin folder with a permission 755 for root:root. Then it checks for the existence of an environment variable `MOZ_PLUGIN_PATH pointing to the plugin directory for Firefox to detect the plugin.
This is the manual step to install the Flash Player plugin for Mozilla Firefox in Ubuntu 7.10
Thus, we have added the export command to .bashrc of the user so whenever he logs in, the environmental variable gets set and thus his Firefox can detect the Flash player plugin.
When things like installation script fails do not give up. A true geek looks into the script and does what the installer does. This is what that is awesome about GNU/Linux and FOSS, even when one door is locked there is surely another door which can be opened. What needs is an effort to search for the door and try opening it
Update: Trying to file a bug lead me to the solution. The md5sum mismatch has been fixed in the package, but uploaded into Hardy repository rather than Gutsy. But we can get the .debs from here and install with dpkg.
Its only a couple of week more before foss.in 2007 begins. Every team participating in Project Day are preparing something or other for the event, mostly are T-shirts and stickers for their project. Though ubuntu-in team had been discussing this for some time, we hadn’t actually put anything in to action. When we and tuxmaniac met this weekend in barcampbangalore, we decided to start some action.
We were pretty impressed with the stickers distributed during the barcamp. Instead of giving tags and coupons, they had print different kinds of stickers which can be stuck on to the shirts. There was sticker to write names, there was “this is my [nth] barcamp” sticker, there was “i am barcamped” sticker and there was a barcamp laptop sticker as well. We felt this idea was cool and we can also make use of it for the project day. We made some enquiries and found out it was well within our financial capacities. So we decided to print the stickers and sought Niyam’s help in designing one for us, as he had been desgining logos for foss conf chennai of late.
We might also be printing some Ubuntu posters to put up in the stall and around the venue. We had come out with a handout pamplet during Carte Blanche which we might use for this occasion as well. All we need is someone who can take a laser printout of the handout and make nice xerox copies of out, some 500-1000 nos will be enough.
We also were thinking about printing some 20 T-shirts to be distributed to the speakers and enthusiastic contributors. Initially there was Yahoo! interested in sponsoring us for the T-shirts. But there were lot of fluster as Y! is not a sponsor for this year’s foss.in and giving a T-shirt sponsored by them might be not welcomed, even might drag us into some unwanted problems. So, we have decided to make a pool of as much as we can and print some T-shirts for the speakers of Debian/Ubuntu Project Day. We are also enquiring whether it is monetarily feasible to print some mugs as well, may be replace t-shirts with mugs as every other team is printing tees.
To print T-shirts, we are looking for people to contribute to the money pool. As the Loco Team has to take care of itself and its needs this time, we are looking for contributions from the team members, from enthusiastic Ubuntu users as well as people from the community to help us in creating a pool so that we can print some nice t-shirts for those people who are speaking for us during the Project Day. We may also use the extra tees to reward people for their contributions and volunteering for various ubuntu-in activities (we do not promise this, but we will try to ).
Looking for your helping hands…
