Ending a presentation with an 'any questions' slide

Ending a presentation with an 'any questions' slide

Pro:

• Engages conversation with the audience

Cons:

• Should have answered questions when making presentation - because know audience and presentation was geared to their needs
• Should stop and take questions at any time - if don't do this people will forget questions or miss something else while writing the questions down so they don't forget.

Wanna be like Mike?

Here's Michael Jordan's move on the golf course: Some guy in the group asks if Jordan wants to play for money, Jordan says of course, the guy asks how much, and Jordan says, "Whatever makes you nervous." Works all the time, seeing as how most people buckle when standing over, say, a $5,000 putt, except, of course, when one of the guys in the group has at least as much money as Jordan and more game than anyone in the world.

iPhone Day

Today is iPhone day. Well the day they become available in the US.
Enough has been said about the iPhone to fill an awful lot of somethings, but I'm going to use the opportunity to talk about Safari.
When Safari for Windows was announced there was lots of speculation about why Apple would do this.
While there is an argument for it being a way to show Windows users what Apple products are like and maybe convert some to Macs. I think that the [main] reason for releasing a version of Safari that runs on Windows is to increase application compatibility with websites and Safari. In turn this leads to a better UX for anyone using Safari: most Mac users and all iPhone users.

Just think of all the websites that don't display properly on in Safari or just flat out even refuse to try to work. With Safari for Windows presenting exactly the same output as the Mac version, developers no longer need a Mac to test their sites. Because OSX couldn't be vitalized, the cost of Safari compatibility udes to be the cost of a Mac. Now it's the cost of downloading a few Mb.

Name badges

I'm a big fan of name badges, so this is very exciting:

Check out these conference badges!

You may provide as much or as little information as you like. Your badge will be more interesting the more information you provide.

They were very receptive to our experimenting with integrating Pathable's social matching service into the event badge.

Some random quotes

"People need uninterrupted time to get things done. 37signals is spread out over four cities and eight time zones. From Provo, Utah to Copenhagen, Denmark, the five of us are eight hours apart. One positive side effect of this eight hour difference is alone time. There are only about 4-5 hours during the day that we’re all up and working together. At other times, the US team is sleeping while David, who’s in Denmark, is working. The rest of the time, we’re working while David is sleeping. This gives us about half of the day together and the other half alone. Guess which part of the day we get the most work done? The alone part. It’s not that surprising really. Many people prefer to work either early in the morning or late at night - times when they’re not being bothered. When you have a long stretch when you aren’t bothered, you can get in the zone. The zone is when you are most productive. It’s when you don’t have to mindshift between various tasks. It’s when you aren’t interrupted to answer a question or look up something or send an email or answer an im. The alone zone is where real progress is made. Getting in the zone takes time. And that’s why interruption is your enemy. It’s like rem sleep - you don’t just go to rem sleep, you go to sleep first and you make your way to rem. Any interruptions force you to start over. rem is where the real sleep magic happens. The alone time zone is where the real development magic happens!" - 37Signals 'Getting Real'

"We all know that knowledge workers work best by getting into 'flow', also known as being 'in the zone', where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration...trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers - especially interruptions by coworkers - all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble." - Joel Spolsky 'Where do These People Get Their (Unoriginal) Ideas?'

"Don’t worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things." - Martin Fowler 'Is Design Dead?'

"We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt. Hack together some bad code that’s functional but still a bit hairy and you’re building up debt. Throw together a design that’s good enough but not really good and you’ve done it again. It’s ok to do this from time to time. In fact, it’s often a needed technique [...]. But you still need to recognize it as debt and pay it off at some point by cleaning up the hairy code or redesigning that so-so page. The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don’t, you’ll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward)." - 37Signals 'Getting Real'

http://en.wikipedia.org/wiki/Archibald_Putt
"Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand."

Missing help file

Rather than a message like this, it would be better for the program to detect that the help file was missing and not even provide the option to launch help.

Checking database permissions in SQL Server 2000

I recently had to write a script to confirm that correct database permissions had been set on a database. Here's how I did it. Hopefully the comments will make it clear what's going on.

--- This uses the syspermissions.actadd column. 
--- This is an undocumented column and is not guaranteed to work in future versions of SQL Server.

SELECT 'ATTENTION:' AS Type, 'Any entries below have not been granted adequate permissions' AS Name

UNION

-- This query will return all user tables that xxxxxx has not granted SELECT, INSERT, UPDATE & DELETE permissions

SELECT 'TABLE', o.name
FROM sysobjects o
WHERE o.xtype = 'U'
AND o.name != 'dtproperties'
AND o.name NOT IN (
 SELECT o.name
 FROM syspermissions p, sysobjects o, sysusers u
 WHERE p.id = o.id
 AND u.uid = p.grantee
 AND u.name = 'xxxxxx'
 AND o.xtype = 'U'  --User Table
 AND p.actadd = 27 ) --  = 1 (SELECT) + 2 (UPDATE) + 8 (INSERT) + 16 (DELETE)

UNION

-- This query will return any view that xxxxxx has not been granted SELECT permission
--  If other permissions have also been granted they will be ignored

SELECT 'VIEW', o.name
FROM sysobjects o
WHERE o.xtype = 'V'
AND o.category = 0
AND o.name NOT IN (
 SELECT o.name
 FROM syspermissions p, sysobjects o, sysusers u
 WHERE p.id = o.id
 AND u.uid = p.grantee
 AND u.name = 'xxxxxx'
 AND o.xtype = 'V'  --View
 AND (p.actadd & 1) = 1 ) -- BITWISE check to confirm that the SELECT permission is set

UNION

-- This query will return any stored procedure that xxxxxx has not been granted EXEC permission

SELECT 'STORED PROCEDURE', o.name
FROM sysobjects o
WHERE o.xtype = 'P'
AND o.name NOT LIKE 'dt_%'
AND o.name NOT IN (
 SELECT o.name
 FROM sysobjects o, syspermissions p, sysusers u
 WHERE o.id = p.id
 AND p.grantee = u.uid
 AND u.name = 'xxxxxx'
 AND o.xtype = 'P'  --Stored Procedure
 AND p.actadd = 32 )-- 32 = EXEC

UNION

-- This query will return any functions that xxxxxx has not been granted EXEC permission

SELECT 'FUNCTION', o.name
FROM sysobjects o
WHERE (o.xtype = 'FN' OR xtype = 'IF')
AND o.name NOT IN (
 SELECT o.name
 FROM sysobjects o, syspermissions p, sysusers u
 WHERE o.id = p.id
 AND p.grantee = u.uid
 AND u.name = 'xxxxxx'
 AND (o.xtype = 'FN' OR xtype = 'IF')  --Scalar Function or In-lined table-Function
 AND p.actadd = 32 )-- 32 = EXEC
ORDER BY 1, 2

Software out of date

This could be better:

It could report version numbers/dates so it is clear what is wrong.

It could say what needs to be done to allow the program to run.

It could say where to go/who to contact to find out how to get the program to run.

Can the program be changed/updated? or is a completely new version needed?

Is 'DataBase' the same as 'Database'?

What on earth does this mean?

There has to be a better way of saying whatever this message is trying to tell me!

Misleading execution times

After restoring a database I was surprised that SQL Server was reporting that it only took 1 second. It definitely felt like longer to me.

It did take longer. Look at the bottom of the screen, it actually took 33 seconds. So why report that it only took 1? And what only took 1 second?

This message is bad because it is unclear and wrong!

How many new items

I like Google reader but there is a definite usability issue in the indication of how many items are in the 'All items' group. It could be 101 or 10000001 for all I can tell. The reason this is bad is that I get an exact figure up to 100 and then suddenly all I get is an approximation with no indication of how accurate the approximation is.
Quite frankly, I'm not interested in finding out how approximate the figure is. I may be there for quite a while.

Bad Error message

I've built up quite a collection of bad coding/message examples.

This is a bad message as it comes from a program that I'm not able to debug. As an end user I shouldn't even be given the opportunity to debug anyway.

Some thoughts on support

I recently made some notes on customer service/support. Thought I'd share them here too.

The Customer Service function is a public face for the company. Customers need to contact the company when they have a problem that is stopping them from doing their job. At this time the customer will get to see how the company values them. Does the company appreciate the customer’s problem and resolve it as quickly and simply as possible? After all, isn’t this all that the customer is interested in?


Customer Service is an expense. It costs money to perform and doesn’t generate any direct income.


When performed well Customer Service can make money for the company. It does this by helping ensure customer retention and upgrade. It also improves the reputation of the company and product to potential new customers through word of mouth.


The Customer Services department has the opportunity to gather valuable information about customers and their use of a system. This can be invaluable when planning development schedules, particularly with regard to prioritising ‘bug fixes’.


While there is a department given the title of ‘Customer Services’ the responsibilities of serving the customer fall on everyone in the company.

Customer Services are part of a company wide process that seeks (among other things) to achieve the following goals:

1. Customers shouldn't have to make calls to the CS department.

We should aim to avoid the perception that something will go wrong!

While perfect software (that never goes wrong) is not a practical reality, it should be the intention of the company to provide a product with no known issues and is able to work under all conditions. Dealing with support calls costs the company money and creates a bad user experience. It should therefore be avoided, where at all possible.


2. When customers do have to call the CS department, their experience should be positive and more than just satisfactory.

Delighted customers are loyal customers, who talk about how good experiences.

“Using a back-tested paper portfolio and an actual case, the authors of a study published in the Journal of Marketing found that companies at the top 20% of the American Customer Satisfaction Index (ACSI) greatly outperformed the stock market, generating a 40% return.
From 1996-2003, the portfolio outperformed the Dow Jones Industrial Average by 93%, the S&P 500 by 201%, and NASDAQ by 335%.”
http://consumerist.com/consumer/personal-finance/how-to-beat-the-stock-market-buy-companies-with-high-customer-satisfaction-scores-261282.php

3. When a customer does have to make a call, it should be as productive as possible.

This is a business. We need to use our time effectively.

The customer should always be left with a positive impression and be satisfied that their issue will be dealt with as quickly as possible.

Because of the effort and cost involved in dealing with a problem, and because we want the customer’s problem resolved as quickly as possible we should aim to obtain all the information we need to resolve the issue, when the issue is first reported. While making multiple calls to the customer to request more information does show to the customer that an issue is being investigated, it can also show a level of disorganisation in not requesting all the information in the first place. It also adds to the total amount to time taken to resolve an issue.


4. Communications between customers and the Customer Service dept should be recorded for two purposes:
i. As part of managing the relationship with the customer.

If it’s a big customer the account manager may want to know about the problems.

If a sales person is going to contact a customer (to try and up-sell or talk about license renewals) they will benefit from knowing if they have had any problems and how they were dealt with.

“I am very sorry for all the problems you have had. We will take this into
account when we look at your license renewal.”

“You’ve seen how valuable
a support contract is and how quickly we were able to deal with the problem you
had.”

ii. To keep track of which areas of the program are having repeated problems/issues.

- Are lots of people having the same problem?
If so, do we need to improve the program/ documentation/ training in light of this?
- Are some customers having more problems than others?
If so, do we need to provide (re)training for them?
- If the first few customers to do something (i.e. upgrade) have a problem?
Do we need to warn other customers who are, shortly, likely to do the same thing?
- Are customers having problems due to a configuration issue that is different to our testing and development environments?
If so, do we need to create suitable test environments? (This might not be financially viable if it was just one customer.)
- If one customer has a problem but finds a work around, do we fix the cause of the problem?
If it’s just that one customer may be not. But if it is lots of customers we will want to fix the problem before other customers become aware of it and have to use the work around. (Remember, it’s not just a case of telling them. Either we tell everyone there is a problem that they may or may not have to deal with – possibly makes us look bad, depending on the circumstances. Or, we wait for them to discover the issue and contact us. While we may be able to provide an immediate solution, the customer has experienced the frustration/ inconvenience/ cost of experiencing the problem.)



Service Level Agreements and Multiple Levels of Support

Service Level Agreements (SLAs) can be formal or informal.

- Formal SLAs are part of a contractual agreement with the customer.

- Informal SLAs are estimated guidelines, either advised to the customer or only used internally.

If neither formal nor informal SLAs exist there is the potential for incidents to be considered unimportant and not be given the attention required.

“I don’t have to do this today, so it can wait for tomorrow.”

Multiple levels of support exist when incidents are handled by different people under different conditions and when a process of escalation exists.

If having service level agreements and/or multi-level support levels, they must be clearly defined so:

- Sales people know what to sell.
- Customers no what to expect.
- Customer Services team members know what the customer expects of them.
- Customer Services team members know what the company expects of them when they are talking with a customer and dealing with an incident.
- Customer Services team members know the conditions under which an incident can or should be escalated. And to whom.
- Developers who have issues escalated to them are aware of expectations and promises that have been set and made.



Incident handling and escalation

At a basic level all calls should be handled in the same way. This includes a taking the call in a professional and courteous manner, but also in gathering some standard information for every incident, regardless of what the incident is.

By ensuring that all calls are handled in the same way:
- The customer knows what to expect, regardless of who answers the phone.
- We know that enough information has been gathered for internal purposes.
- Sufficient information is available for anyone to whom the incident is escalated.

“Plenty of customer service people would like to do the right thing. They'd like to fix the problem that's presented to them. But frustration hits when the policies and procedures and metrics they've been given to work with won't let
them.

For a service rep in this particular situation, "doing my job" means making the person go away, while "doing the right thing" means taking initiative and actually solving the problem.

Getting your team in alignment (having their job match their tools match their mission) is perhaps the first job … to do.”
http://sethgodin.typepad.com/seths_blog/2007/05/alignment.html

What information to gather

In addition to the basic information gathered for each call/incident, specific information may be needed for different types of issue or product.
- If an incident relates to installation we need to know X, Y & Z.
- If an incident relates to printing we need to know A & B.
- If an incident relates to … we need to know F, G & H.
- ….

While it is probable that an initial version of the question list could be developed now, it is likely that such a list of questions can only be fully developed over time.

A question list should not be set in stone and is likely to develop over time and in line with enhancements and developments to products.

A question work flow may be an appropriate way of managing which questions should be asked, based on the incident being reported.

In addition to the list of questions, details explaining why each specific question is asked should also be recorded. This aims to remove any doubts as to why the questions should be asked.


Documenting an incident

The most important part of handling a reported incident is to:

WRITE EVERYTHING DOWN!

Or, better still record the call and use a speech to text tool to handle the dictation. Or, even better still apply the text to speech processing to the call as it is happening, so any corrections can be made at the time.

It is important that nothing is assumed. When recording information it is important to record exactly what the problem is, which version of which product it is experienced in and all the steps needed to recreate it.

Specifics are very important.

Without specific details the chances of finding and resolving an incident are greatly reduced. This is due to the fact that most incidents only occur under very specific circumstances.

The only questions a developer handling an escalated support call should be “What is the reference/log number for the call/incident?”

They then need time to read the details documented so far (to get up to speed) before being expected to be able to respond to, discuss or investigate the issue.


Reasons to record everything that happens as part of an incident investigation:
- So not relying on memory to know what happened or has been tried so far. - Saving repetition of asking or attempting possible soultions.
- So the solution can be documented so it is available if needed again.
- So the solution can be used to patch code so it can't/doesn’t happen again.
- So that if another person needs to get involved in solving the problem they know all that has happened so far.


How rest of the company can help the support department/process:

· Provide documentation for all parts of the program.
· Share training/debugging tips and solutions.
· Document solutions and resolutions to problems.
· Any more ideas . . . ?