23. April, 2013
- Suddenly appear out of nowhere after longer periods of (felt) absence
- Create huge gusts of dust
- Make high and immediate demands for change
- Vanish as fast as they appeared
As a friend of mine once said, “managers are a service.” I don’t bother my manager with my daily work (that’s what I’m paid to do) but for things that I can’t solve myself. When I need feedback and someone else starves me. When I need a tool but the company doesn’t give me budget or the authority to sign it. Things like that.
Helicopter managers don’t help. Most of the time, you don’t notice that they’re there. When the suddenly jump to action, a lot of dust gets blown around. But dust isn’t important. Usually, you can safely ignore dust. Dust only becomes a problem when it’s disturbed. As soon as it gets airborne, it can blind or suffocate you.
Since the helicopter manager is always in a hurry, they don’t have time to see change happen. They just start it. But they’re not there when the flaws and shortcomings of the change become apparent.
When you suffer from one of those, always keep a bucket with dust around to clog their engines.
12. April, 2013
A short summary of the presentation ”UI Best Practices & Trends” held by Roland Studer of We Are Cube (slides).
- UIs are often bloated, confusing and frustrate users.
- A major factor is that features are often requested by people who won’t have to use the software later i.e. by (self) “important” managers. A variation of “Nothing is impossible if you don’t have to do it yourself.”
- “Don’t make me think” by Steve Krug (Amazon)
- “The interface is your product” (“Getting Real – The Book“). Customers don’t care about the code or the effort which went into the product, they only see what you show them on the screen.
- “Show me where I am”
- breadcrumbs, highlight tabs, use tree navigation
- “Use the F-Pattern“
- eyes travel left to right, top to bottom in Western cultures
- “Emphasize in Tables”
- gray out less important values, make important ones bold, group with color, use gauges instead of numbers
- “Affordance (sic): Show what’s interactive”
- Make it obvious for users to see where they can click
- “Make frequent uses accessible”
- Show only the most important actions as buttons (max. 5).
- Put the other, less signification actions in a popup menu.
- “Caution with icons”
- “A picture says more than 1000 words but which words exactly?”
- Icons can be confusing, hard to remember and they depend on culture/training.
- Offer at least user preferences to replace them with text or show text in addition to the icon or use tooltips.
- “Emphasize primary actions”
- Make the button stand out which the user most likely wants to click next or reduce visibility of less likely options (like “[Submit] [Cancel]“).
- Be careful that the visual cue doesn’t conflict with “this button is disabled”
- “Avoid OK / Cancel”
- Instead of asking “Is it OK to delete?”, ask “This object is still be used. [Delete Anyway] [Keep]“
- “Use undo if you can”
- Avoid confirmation dialogs. No one ever reads them.
- The user should never be able to do anything that isn’t reversible in some way.
- Allows users who got confused with an icon (see #6 above) to unto destructive action on touch screens.
- “Avoid left aligned form labels“
- The eye is only able to align elements when they are close enough.
- Right align labels, rely on browser search for locating elements if you have too many of them (which you shouldn’t)
- Or put the label on top of the fields (but this works better for forms where you have to fill in every single field)
- “Be nice to user input”
- Support “slang” like “next Tuesday” or “now” in date fields
- Keep illegal values so the user can edit them
- “Prevent errors”
- Calendar popups
- Offer a list of valid inputs in a drop-down list or use radio buttons
- “Instant Feedback”
- Show what has been entered correctly as well as what’s wrong.
- Display validation errors immediately (when the focus is lost) instead of waiting for the user to click on a “Submit” button
- Use tooltips on disabled buttons to explain how to enable them
- “Help users recover from errors”
- Avoid “There have been errors” dialogs; they aren’t useful in any way.
- Don’t tell what’s wrong, tell how to fix the error. If you don’t know how to fix it, will the user?
- “Responsive Web Design” – adjust the layout to available screen space. “Mobile first” helps to concentrate on the core features of your application. “Reduce to the max”, avoid distractions, show only the absolute minimum of data. Anything on the page begs to be noticed, so even if the user doesn’t read it, it will still take a tiny bit of concentration to ignore!
- There is a trend towards flat and minimal design. Example: http://basecamp.com/ where a lot of things on the page are interactive (i.e. responds to clicks) but almost everything looks like plain text.
- “Actions only on hover” – Show available actions only when the user hovers over some part of the page. Drawback: Doesn’t work on touchscreens since the user can’t “hover”
- “Implicit feedback” – Show a “saved successfully” message. Give hints in text fields.
Always keep in mind:
Developer != User
Product Owner != User
UI Guru != User
Do usability testing. If you can’t, try installing the product on a laptop and ask someone in the corridor to use it for five minutes. A little is better than nothing. You’re blind to your own prejudices.
26. February, 2013
David Blake posted a current overview of Man in the Middle type attacks: 15 Surprising Ways You Could Fall Victim to a Man in the Middle Attack
- Key-loggers (hard- and software)
- Browser plugins
- Cameras (a.k.a Shoulder Surfing)
- Wireless attacks
14. February, 2013
A unit test checks a certain feature of the software. When it fails, you usually know exactly where to look for a place to fix the problem. They are short, compact and fast.
They come at a cost, though: You have to replicate the setup code in your test.
This is an important point. To use a feature of your software, you always have some set up to do. This set up has to exist in your production code. For unit tests, you will have to copy some parts of this code into your tests because usually, the setup of the production code simply isn’t fine grained or flexible enough to be useful for tests. Think tests which check the error handling: Your production code usually can’t build mock objects that raise errors when certain methods are being invoked.
An integration test reuses the production configuration. It tests many features at once, in the same order and with the same or at least a very similar environment that your final application will use. They are high level and often much easier to set up. But that comes at a cost:
- They are slow
- When they fail, there will be many places which could cause the issue, so fixing them is more expensive
- They break more often because you have more dependencies
- Setting up a test for the “success” scenario will be simple but injecting mock objects to cause exact error states will be much harder
So be aware what kind of test you’re writing.
8. February, 2013
“Things users don’t care about” is something every software developer needs to know about.
Kudos go to Thomas E. Deutsch for finding and telling me about it.
7. February, 2013
Finally! 100’000 points of reputation on stackoverflow.com!
7. February, 2013
The Common Vulnerabilities and Exposures or CVE is a registry for security related flaws and computer systems.
The old counting system allowed only for 9’999 bugs per year.
That’s no longer enough.
Isn’t that scary?
25. January, 2013
On Wednesday, GitHub improved their code search. A few hours later, a couple of people had tried “begin rsa private key” and got more results than any sane person would anticipate. Just in case, this isn’t a problem of GitHub, the same problem can be found on pastebin or with Google.
There are several reasons for people to publish sensitive data:
- They don’t know what they’re doing (ignorance)
- They are sure “no one will ever find out” (security by obscurity)
- Distributing sensitive data anonymously (crackers)
- It’s easier that way (laziness)
It’s not a corner case, either. The SQL*Plus tool from Oracle has no easy way to set the password from a script except by passing it on the command line which effectively publishes the password to any user on the same computer. You can install a “client-side Oracle wallet” to fix this.
But the common issue behind all that is that it’s either too easy to do it wrong or too hard to do it right. Just to see how bad the situation is, I asked for a secure web login/example on stackoverflow.com. The answer was basically “it’s too complex to do.”
22. January, 2013
“Analyzing and understanding the memory use of an application is challenging,” says Ian Bull in his blog post “10 Tips for using the Eclipse Memory Analyzer” and gives you useful guidelines how to wade through the data which Eclipse Memory Analyzer (MAT) collects for you.
21. January, 2013
If you’re the guy in the team who solves the impossible problems, you will eventually run into the worst of all design patterns: Singletons. Which are implemented in Java using final (static) fields.
Sebastian Zarnekow came up with a way to change that. Following the timeless advice from the Matrix – there is no spoon -, he found a way to modify (some) final fields.
As I said before, this is a desperate measure, so use it wisely. But remember this tool next time when you need to mock a singleton for a test case.