Optimizing the JBoss-EAP Performance

http://www.theserverside.com/tip/13-Best-Practices-for-Optimizing-the-JBoss-EAP-Platform

Lead Without Title | Robin Sharma | Leadership Development, Personal Development

Lead Without Title | Robin Sharma | Leadership Development, Personal Development

Shared via AddThis

create and share a folder with .bat file

Simple .bat file to create a folder and share that folder with full permission and give access to Everyone. Just put below four lines of code into any textpad save a .bat file.


Md E:\MyFolder
Net Share MyShare=E:\MyFolder
Cacls E:\MyFolder /e /r Everyone
Cacls E:\MyFolder /e /g Everyone:C

HOWTO:Setting up a Subversion Server on Windows Server 2003

Recently we have migrated our repository from Serena PVCS to SVN. Here the configuration details I used to configure Subversion(SVN) on windows 2003 server.
SVN (Tigris.org) got pretty cool exe file (Svn1ClickSetup-1.3.3.exe) which will include all it's necessary software's in a single bundle namely the software's are Subversion, SVNService and Tortoise SVN client. We just need to keep on clicking next and verify the installation location by defualt it points to C:\Pr0gram Files\subversion.

Things To Do:

1. Download the latest version of Svn1ClickSetup-1.3.3.exe from http://svn1clicksetup.tigris.org/.
   
   
2. Double click on Svn1ClickSetup-1.3.3.exe and it initialize installation process just keep looking at installation window and keep hitting on next button all the way out to finish set up process.
   
   
3. Svn1ClickSetup-1.3.3.exe will install Subversion command line tool in C:\Program File\Subversion\ and say Next now subversion will automatically pickup Editor which is Notepad.exe leave it as it is if you want you can change it to text pad or Edit plus what ever you like and say Next now it is going to create Repository (Here is the place all your work gonna save) by default it points to C:\svnrepos (if you want to change you can change it, I changed it and I created like E:\svn_repository) and say Next (this is a bit important stuff here we are going to deal with Authentication) now it points a window asking user name and password this is nothing but your admin credentials I have given as admin/sirish and say Next now it will prompts window asking project name give anything you like or your project name (testproject) and say Next now it is going install SVN client called TortoiseSVN (TSVN) and say Next this will install TSVN and it prompts a window asking Restart your system to complete installation. Just choose Restart and say Ok this will restart your System.
   

Now you are pretty much done with SVN configuration on just mouse clicks see how easy it is :-) Now we see how to check-in and check-out a project to SVN using TSVN Client.

Just give right click on desktop you see the TSVN options as mouse short cuts something like,



Now open SVN Repo-Browser for this choose SVN Repo-browser option on mouse right click and it will ask for URL of the repository provide URL like below, http://localhost/ or http://127.0.0.1/



Subversion will open project(s) window something like below where you see the project you created while installing(testproject) (I changed it to FirstProject)



All the folders under FirstProject are empty. FirstProject will have 3 sub folders called branches, tags, trunk. generally trunk will hold development version of the code so go ahead and drag and drop your project folder inside this trunk or you can add the project by right-click and Add Folder option but drag and drop is cool thing to do.

Once you drag and drop your project folder it will open up a pop up window asking enter log message so enter something you like (always write clear message saying what you gonna check-in)



So you are done with check-in project into Subversion. Let's go and check-out the same project.
create a folder on desktop with same name of the project (just for consistency) and then check out the project. Right click on the folder you just created and select Check-out.



Then subversion open up a window showing Repository URL and check-out location just make sure they are right ones and say ok.



It will download project into local directory. Then try to modify some files and check them back to repository.

Configuring Users (Access Rights on SVN)

Now we need to edit multiple files to configure Users, User Rights and to provide restriction to SVN at group level by creating user groups something like Developers, Testers.

To do so by default SVN got it's won user configuration file. So open E:\svn_repository\conf directory under we find 3 files namely,

1. authz
2. passwd
3. svnserve.conf
   

Edit svnserve.conf and do the following changes.

1. uncomment password-db = passwd so SVN will pickup users from passwd file.
2. uncomment anon-access and update anon-access = none.
   
3. uncomment auth-access and update auth-access = write.

Now edit passwd file and add user name and passwords something like below,

[users]
admin=India@123
sirishg=sirishg
david=david

Now we added 3 users for SVN and we need to create groups and provide access on project level. Some people will access some projects only. If user is not assigned to any project he can't able to access the project.

Now edit authz and create a group and provide access at project level.

[groups]
development_group = sirishg,david
admin_group=admin

I have created two groups called development_group and admin_group and I assigned users to the groups. Remember all the users added in the groups should be declared in passwd file.

Now providing access to all the users to just see the repository. The following wild card entry will make every user can be able to see all the project but he/she can't be able to access the project unless he/she assigned to that project.

[/]
* = r

[/testproject/]
@development_group = rw
@admin_group = ''"

About command means for testproject development_group have read and write access and admin_group don't have any rights. The same way you can provide access to other projects too.

authz Conf Files look like,

[/]
* = r

[/testproject/]
@development_group = rw
@admin_group = ''"

passwd Conf Files look like,

[users]
admin=India@123
sirishg=sirishg
david=david

svnserve.conf Files look like,

[general]
anon-access=none
auth-access=write
password-db=passwd

So now you can try accessing your repository from repobrowser Now SVN will prompt you user name and password.

Applets are not running on Internet Explorer 7.0

I think there was an issue with applets on Internet Explorer 7.0. When I tried to run some applets on my windows 2003 server (SP2) box with IE 7.0 and JDK 1.5 version I could not able to load applets on my browser. I tried in almost all known ways by enabling applets through browser setting Tools -->Advanced and from java console (control panel --> java console --> Advanced) but no luck finally I thought to uninstall the java and reinstall it again and did the same but still no luck so finally I have installed lower version of Internet Explorer version 6.0 and it started working...
I think IE 7.0 has some issues still. But IE 7.0 has got some pros and cons as per my limited usage experience...

Pros:

• Rich look and feel
• Tabbed browsing
• Implemented Add-on concept as Mozilla Firefox had.

Cons:

• Though you enable Add-ons still browser through you message that you have not enabled add-on facility which really frustrates.
• As I told Applet issue.
  
• When we say Add-on user will easily sense that MicroSoft is trying to follow Mozilla's style of providing add-on's.

Fix for this issue

It started working by doing this way uninstall IE 7.0 and JDK 1.5 and then start reinstalling IE 7.0 and then install JDK 1.5. This will solve applet issue.

Error Reporting through E-Mail using Log4j (SMTPAppender Class)

This could be one of the cool thing if you get an intimation through an email when ever your application is facing the problem in production or test environments apart from this you get log file as well so we can decrees the turn around time some what in fixing and issue and making your environment up. A few months back I have implemented the same thing for one of our production application and I have used log4j for logging and emailing the log file when ever log file get populated with error level messages.
In log4j api we have one class called SMTPAppender which will email us our log file when ever log file is populated with error level message. Just needs to configure log4j properties file with all SMTP server details.

Note: Make sure that you should have mail.jar and activation.jar files in your class path.

log4j.properties:

log4j.rootLogger=INFO, filer ,SMTPTest
log4j.appender.filer=org.apache.log4j.RollingFileAppender
log4j.appender.filer.layout=org.apache.log4j.PatternLayout
log4j.appender.filer.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %-5p [%t] %c{2} - %m%n
log4j.appender.filer.File=C:\\COMSProduction.log
log4j.appender.filer.MaxFileSize=1000KB
log4j.appender.filer.MaxBackupIndex=4

#####################
#SMTP appender properties#
#####################

log4j.appender.SMTPTest=org.apache.log4j.net.SMTPAppender
log4j.appender.SMTPTest.Threshold=Error
log4j.appender.SMTPTest.BufferSize=512
log4j.appender.SMTPTest.layout=org.apache.log4j.PatternLayout
log4j.appender.SMTPTest.layout.ConversionPattern=%d %-4r [%t] %-5p (%c:%L)%x - %m%n
log4j.appender.SMTPTest.SMTPHost= smpt.youcompany.com
log4j.appender.SMTPTest.To= me@who.com
log4j.appender.SMTPTest.From= me@who.com,user@who.com
log4j.appender.SMTPTest.Subject=COMSProductionLog - <>

EmailSender.java - Load properties and configure SMTP properties with log4j.
------------------

import org.apache.log4j.Category;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.PropertyConfigurator;
import org.apache.log4j.net.SMTPAppender;

import java.io.InputStream;
import java.util.Properties;

/**
* Created by IntelliJ IDEA.
* User: sirishg
* Date: Apr 5, 2007
* Time: 4:38:45 PM
* To change this template use File | Settings | File Templates.
*/

/**
* This class is responsible to email your application log file to SupportEngineers/Developers when ever application is caught with errors.
* I am using SMPTAppender(from apache log4j) to do this job.
*/

public class EmailSender {
public static Category log = org.apache.log4j.Category.getInstance(EmailSender.class.getName());

public static void postEmail() {

Properties properties = null;
try {
properties = new Properties();
InputStream inStream = LogManager.class.getResourceAsStream("log4j.properties");
properties.load(inStream);

log.info("Trying to load log4j.properties file!!");
PropertyConfigurator.configure(properties);
log.info("Successfuly loaded the property file!!");
} catch (Exception e) {
log.error("OOPS...log4j.property file has not loaded!!");
e.printStackTrace();
}

/**
* Call SMTPAppender and set all required fields to that. you can set directly from here or you can load parameters from you log4j.properties.
* I prefer to load from log4j.properties hence you will get the chance to change perameters dynamically with out recomiling your code.
*/
try {
log.info("Invoking the SMTPAppender class");
SMTPAppender emailAppender = new SMTPAppender();
if (properties != null) {
emailAppender.setSMTPHost(properties.getProperty("log4j.appender.SMTPTest.SMTPHost"));
emailAppender.setFrom(properties.getProperty("log4j.appender.SMTPTest.From"));
emailAppender.setTo(properties.getProperty("log4j.appender.SMTPTest.To"));
emailAppender.setSubject(properties.getProperty("log4j.appender.SMTPTest.Subject"));
}
emailAppender.setLayout(new PatternLayout());
emailAppender.activateOptions();
log.addAppender(emailAppender);
} catch (Exception e) {
log.error("got an error in SMTPAppender, the errors are::" + e.getStackTrace());
e.printStackTrace();
}
}
}

PostEmailTest.java
-- Small test and try to do some mistake and put an error entry into log file now see you will get an email with your log file.
public class PostEmailTest {
public static void main(String[] args) throws Exception {
LogManager manager = new LogManager();
Logger log = manager.getLogger(PostEmailTest.class);
String str = "Sirish";
if (str.equals("SIRISH")) {
log.info("both strings are equal....");
} else {
log.error("Strings are not equal....!");
/**
* Finally we rached to what we are looking for. now we got one error entry into log file and this is the time to email log file to
* SupporEngineer so invoke EmailSender class and send .log file.
*/
EmailSender.postEmail();
}
}
}

Why Managers Fail

Good one...
http://managementcraft.typepad.com/management_craft/2008/06/why-managers-fa.html

JUnit testing tips

As we used to write our JUnit test cases for all Story cards we develop, well we follow TDD (Test Driven Development). Here are the rules we follow for our JUnit testcase as part of our TDD...

• Never break others test case.
• Don't update any database values as part of your JUnit testing. (But we can read DB values if required.)
  
• Test your business logic no need to test java or other API's as they are well tested.
• Try to avoid Mock Objects usage. (I think some times this mock objects will cause problems when you debug your test case - I am not quite sure to give any instance but I think so)
• And he used to tell one more thing Clean first before committing something back to repository.
• Ensure your JUnit test is passing on cruise control. Some time JUnit will pass locally when it actually running along with Cruise Control test beds it fails so need to ensure till you get positive build results other wise need to fix again.
  

Cruise Control configuaration over VSS

Nice article on how to configure Cruise Control over VSS.

1. http://www.spiderlogic.com/news_threads/articles/cruisecontrol.html
2. http://cruisecontrol.sourceforge.net/gettingstartedbindist.html

http://www.java-tips.org/ - A Good site for a real quick help in java

A very useful and good site for basic things for a quick review for basic and advanced java stuff.
http://www.java-tips.org/

Execute .sql script file using java

A few days back I tried to execute our database scripts file using java in a plain way but I am not sure how good it is? but I am done with my work with no known issues but still I'm thinking is that right way to parse entair .sql file and pass the each line to JDBC API and ask JDBC API to execute that line of SQL? Here it is the method I used...

public boolean executeDBScripts(String aSQLScriptFilePath, Statement stmt) throws
IOException,SQLException {
boolean isScriptExecuted = false;
try {
BufferedReader in = new BufferedReader(new FileReader(aSQLScriptFilePath));
String str;StringBuffer sb = new StringBuffer();
while ((str = in.readLine()) != null) {
sb.append(str + "\n ");
}
in.close();
stmt.executeUpdate(sb.toString());
isScriptExecuted = true;
} catch (Exception e) {
System.err.println("Failed to Execute" + aSQLScriptFilePath +". The error is"+ e.getMessage));
}
return isScriptExecuted;
}

How Hard Could It Be?: Five Easy Ways to Fail...

As useal I was surffing net and I found a very good article a must read one by Joel Spolsky is the co-founder and CEO of Fog Creek Software. Here it goes...

http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html?partner=fogcreek

How ever I copied to here as it moves off

A huge number of technology projects go wrong. This is news to no one. Whether you run a software company with a number of ongoing development efforts or you have a nontech company that hires consultants here and there to provide systems integration, chances are you've bumped up against this problem. Delays, blown budgets, and outright failures are so common in the software world, in fact, that it's hardly newsworthy when a project is years late and millions over budget.
In 2003, for example, I flew out to Los Angeles for one of those conferences that Microsoft (NASDAQ:MSFT) occasionally puts on for software developers. At the event, Microsoft made a lot of exciting announcements about some of the revolutionary new features coming out soon in the next version of Windows. Looking back at my notes, I see that one of the important new features was something called WinFS. I'll spare you the boring details, but basically WinFS proposed to combine the file system features of your operating system (storing files and folders on a hard drive) with database features (where you store individual data records for easy search and retrieval) into one big unholy file-and-database mishmash.
This was quite an ambitious undertaking. WinFS was in technical terms approximately the equivalent of rearranging the nation's transportation system to accommodate flying cars. Yes, it would put airlines out of business, and yes, every garage would need to be widened a bit to accommodate cars with wings, but hey, we oughta be able to deliver this in a year or so. Two years, tops.
Three years passed. A manager at Microsoft named Quentin Clark announced on his blog that WinFS simply could not be delivered on time, and that it was holding up the launch of Microsoft's latest operating system. So it was going to be delayed and shipped, maybe, as a feature in a future database--meaning that it was not going to combine the database and the file system, which was the only thing that made it interesting. So how can you tell when one of your technology projects is destined to be another WinFS? Here's my five-step guide to ensure software failure:
Mistake No. 1: Start with a mediocre team of developers.

Designing software is hard, and unfortunately, a lot of the people who call themselves programmers can't really do it. But even though a bad team of developers tends to be the No. 1 cause of software project failures, you'd never know it from reading official postmortems. In all fields, from software to logistics to customer service, people are too nice to talk about their co-workers' lack of competence. You'll never hear anyone say "the team was just not smart enough or talented enough to pull this off." Why hurt their feelings? The simple fact is that if the people on a given project team aren't very good at what they do, they're going to come into work every day and yet--behold!--the software won't get created. And don't worry too much about HR standing in your way of hiring a bunch of duds. In most cases, I assure you they will do nothing to prevent you from hiring untalented people.

Mistake No. 2: Set weekly milestones.

Say you're remodeling your kitchen. That guy you hired to do the work has done a lot of kitchens before, and can estimate the cost of the job without having detailed blueprints. But software developers are building things that they've never built before. If they had, they'd just sell you another copy of the CD-ROM. So rough estimates are impossible. They need to draw up detailed plans before they start writing code. Whether you're the customer or the developers' manager, your job is to make sure they come up with that blueprint. When you ask developers for one, however, many of them will respond by creating a schedule that breaks pieces of the process into weeks. This may seem perfectly reasonable, but it's not. If you let a software team submit a schedule with big chunky estimates of time (by big I mean more than two days of work), you can be almost certain that they're not considering every detail that needs to be implemented, and those details will add up to a huge delay.

Mistake No. 3: Negotiate the deadline.

What's worse than accepting a schedule that breaks down a software project by the week? Demanding that a team commit to completing its work much sooner than forecast. In my experience, most developers are optimists and will take your cue and engage in split-the-difference bargaining. You'll have a nice, agreed-upon schedule that you'll never stick to.
Think of it in these terms: Mama walruses deliver their calves at the end of a 15- to 16-month pregnancy. You might ask the mother to commit to 15 months and she might say, "No problem!" Or you might say, "Fifteen months? Are you crazy? We need this in eight months!" Of course, haggling like this can't possibly make things happen any faster, and even if you get the walrus to agree to an eight-month timetable, I'll let you in on a little secret: It'll never happen. You can have a schedule that says 11 months, but you'll still ship in 15 months, because that is how long it takes to make a baby walrus. Sixteen, sometimes.

Mistake No. 4: Divide tasks equitably.

Here's a great way to torpedo any project. Make a list of all the work people have to do, and then reassign things to different people to balance the project. If Mary has too much work, give some of her tasks to John. This sounds completely sensible, so you won't be challenged.
But I promise you, in the long run it's sure to cause problems. That's because when one developer steps in to replace another, it's reasonable to assume that the new one will work at about one-tenth the speed. John's going to have to spend untold hours figuring out all the things that Mary already knows about her area of code. And John can't fix Mary's bugs as fast as Mary can because Mary knows where all the hidden traps are.

Mistake No. 5: Work till midnight.

Let's say a project should take six months at 40 hours a week to complete. If you told everybody to work 60 hours a week, you could finish the development in four months flat. The software team might even embrace this challenge because it will make them look like heroes ("How great is that Walrus team? They're here every weekend!"). This should work, right? Guess again. There's a whole body of literature establishing that working more hours doesn't produce software any faster. Edward Yourdon, the software entrepreneur and author, dubbed this kind of project the "death march."
Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.
Compelling them to spend even more hours sitting in front of a computer won't really translate into more output--or if it does, it will be the wrong kind of output. When their brains are completely fried, software developers are almost certainly going to do more damage than good, writing unusable code and introducing bugs galore. And if you do ban the Internet and multiplayer games to force them to keep writing code past their natural bedtimes, well, they'll probably start quitting on you. Running a death march is not the only way to make a project late and a budget buster. But it is a surefire way to do so.
If these are all the ways you can go wrong, how can you ensure that a project actually goes right? First, you have to hire superstars. At Fog Creek, we tend to review about 400 candidates for every full-time hire, because the best developers can be 10 times as productive as the merely excellent developers.
Second, demand fine-grained time estimates from the developers. Yes, it's difficult for developers to predict how long it will take to build a new application. That's why they need to create a reliable blueprint before every project.
Once you have that schedule in hand, don't try to push up the deadline. If the project can't be completed in what you consider to be a reasonable amount of time, the answer is not to negotiate a better-sounding schedule. The answer is to get more resources, move back your ship date, or remove features.
As a project gets going, you'll at times be tempted to reassign work. But reassign it with care. It takes a long time for new developers to get up to speed on someone else's code. I think it's good to rotate developers through different jobs so that you don't have any irreplaceable individuals, but I do this cautiously and build an extra three weeks into the schedule for the incoming developer who's learning the new code, and an extra week for the outgoing developer who is teaching the code to the new person.
Finally, encourage your staff to work a sane 40 hours per week. Seriously. Except for occasional, very short bursts of activity to meet a deadline, we at Fog Creek work eight-hour days. In the technology world, it's better to view a big project as a marathon, and not a sprint.

Not the User's Fault from Jono at Mozilla Labs

I found this on Internet worth to read it...I think Author is from Mozilla Labs.
These things I believe. These things I believe about software development and user-interface design.

1. Why write code?
Software is for humans, not for computers.
Software is only as good as the improvement it makes to a human being’s life.
Are we making someone’s job easier? Letting them have more fun? Helping them learn?
Helping them keep in touch with friends and family?
Are we making the world a better place?
2. What do people want?
Most people do not want a computer.
They don’t even want software.
For us software developers, this is a painful truth.
If people don’t want a computer, why do they use one?
* Email — for writing to other people.
* Instant messaging — for talking to other people.
* The web browser — for reading what other people have written.
* Word processing — for writing something you’re going to print out and show to other people.
* Graphics — for creating artwork. To show to other people.
* Presentation — for communicating your brilliant plan. To other people.
* Games — especially games that you can play online. With other people.
* Social networking websites — Enough said.
The computer is merely an intermediary. A poor and frustrating one. It is a necessary evil that people put up with in order to get what they want.
What they want is a better way to talk to each other.
3. Why does software succeed or fail?
We software developers, being not exactly social creatures by nature, must work extra hard to understand the social impact our software will have. If the social effect is not what people want, the software goes unused.
We software developers, being not exactly average users, must work extra hard to understand how average users will relate to our software. We see the trees, they see the forest.
We software developers have often been confused and frustrated when a clearly superior technology fails, while a clearly inferior technology spreads like wildfire and takes over the world.
We were surprised because we want each technology to be judged only by its cleverness, its raw power, the cleanliness of its architecture, the purity of its ideas. We were blind to the user experience, to what each technology meant in the bigger picture of a person’s life.
To the people buying and using the “clearly inferior” technology, exactly the opposite was true.
To the user, the interface is the product.
4. Why is there not more Linux on the desktop?
For open source software to take over the world, we’re going to have to do a lot better at user interfaces than we have been doing.
How do I know?
Open source has already taken over the invisible parts of the world: the servers, the infrastructure, the things users need not touch directly.
Mozilla, the most user-experience-focused of open-source companies, has the most adoption by end-users.
People say things to me like, “Linux is only free if the value of my time is zero.”
These are not coincidences.
At one time, the way of open-source software development was thought impossible. But the techniques were invented. The way became possible; then it became successful. Now the techniques are becoming widely known.
The way to make open-source UI design successful is still unclear. We must invent the techniques.
5. Are users dumb?
User interface design is not about dumbing things down for the poor stupid user.
We software developers, understanding the software as we do, find it easy to look down upon those who lack our understanding.
This is wrong.
Users aren’t dumb. They just have better things to do with their lives than memorizing the internal data model of our screwy software.
When software is hard to use, don’t make excuses for it. Improve it.
When a user makes a mistake, don’t blame the user. Ask how the software misled them. Then fix it.
The user’s time is more valuable than ours. Respect it.
Good UI design is humble.
6. Is UI design marketing?
User interface design is not marketing.
Software developers loathe marketing, so if they think that UI design is marketing, then they will loathe UI design.
The qualities of software that make for a good advertisement or computer-store demo are not the same qualities that make software usable and pleasant to work with long-term, day-in day-out. Often these qualities are opposites.
A shopper may choose the microwave with more buttons, because it seems “more powerful”. However, the shopper will soon find out that it does the same thing as any other microwave, you just have to spend longer figuring out which button to push.
It is easy to fool people into buying something that is against their own best interest.
Don’t do that.
7. What is the task of the UI designer?
Let us talk about that microwave some more.
The microwave with the most buttons may be most popular, but it is not the best microwave.
The best microwave has no buttons at all.
It doesn’t need any buttons because it already knows how long you want your food cooked and how hot. You never need to set the clock, either: it’s just always right.
The no-button microwave may not be reachable, but like a guiding star it shows us the direction we should travel.
Users do not know what interface they want. Users do not know what features they want.
Users know the tasks they want to do, and the problems they have.
We learn more by watching the user work than by asking the user.
The job of the UI designer is to provide what the users need, not what the users say they need.
It is to make tasks easier, not to provide features.
8. Where is the science?
User interface design can be approached scientifically. But usually isn’t.
Until we observe people using our software for real, our design is guesswork and superstition.
These things can be measured and given numbers:
* What program features are being used most frequently, and least.
* The number of mouse/keyboard interactions required to perform a task.
* The time it takes a user to figure out how to do a task.
* Rates of error.
* How quickly task-completion-time and error-frequency decrease as a user gains experience.
An interface’s efficiency and learnability are empirically determinable quantities.
They are not matters of opinion.
Every user is different, but that’s why we have statistical methods.
The science of design can tell us that interface foo is X% more efficient than interface bar, but bar is Y% more learnable than foo.
Choosing between foo and bar — that’s where the science ends and the art begins.
9. Is change good or bad?
Change has a cost. Change disrupts the user’s habits. Change forces the user to learn something new.
Sometimes the new UI is so much better than the old one that the change is worth the cost.
Sometimes it isn’t.
The trick is knowing when change is worth it.
10. What is the evil of the bad interface?
It is a sin to waste the user’s time, break the user’s train of thought, or lose the user’s work.
Bad user interfaces do all three. Frequently.
Most interfaces are bad.
I do not use the word “sin” lightly.
Because of bad user interfaces, an action taken based on a reasonable assumption or out of habit often results in broken trains of thought, wasted time, and lost work. This is called “user error”, but it isn’t. It is programmer or designer error.
When we blame the user, we teach them that technology is perfect and that the errors are their own. Because technology is hard to use, we are teaching a generation to be afraid of technology. We are teaching a generation to believe in their own stupidity. This is a sin, too.
It’s not the user’s fault.