Why It is Stupid to Buy a SmartTV

There are no regulations concerning what information can & cannot be collected with smart devices, nor how that information is transmitted. This article from the BBC explains how LG’s SmartTV sends the names of his family members in clear text across the internet— something that most people would be uncomfortable having publicly available.

Besides selling your private information to any and all advertisers or 3rd party entities willing to pay for it, none seem to have anyway to prevent those 3rd parties from transferring it to others (aside from legal clauses — which would be hard to prove & a lengthy process to fix). Nor it there anyway to redact information once released to 3rd parties.

But this is only part of the threat to personal security because it would be trivial for a person with the technical ability or a warrant to obtain any and all information collected by such devices. Smart devices — those with convenience features tied to internet connectivity — are trojan horses for violations of privacy far more invasive and covert than anything else and rely of consumer ignorance to operate unfettered:

http://www.bbc.com/news/blogs-echochambers-29826642

The only solution is to either never connect the devices to the internet, block all traffic or not purchase them at all.

Advertisements

Tech Crime & Punishment

In a recent article Sophos had a poll asking what the appropriate sentence for tech related fraud — such as fake “Windows Support” call saying you have a virus and asking for $300 to fix it over the phone. I have covered what to do with any unsolicited phone calls before (The “short” answer: do not believe any claim of identity and ask for proof such as their employee ID#, the company they are representing {which they are often obligated to give you}, the case number for your issue, & a callback number and hang up. Then look up the company contact info — make sure the company is on the up and up {has a physical address, look up consumer complaints about the company, etc.} — and call the official number with your case number if it all checks out. And never be afraid to get a second opinion — if a person tells you not to bother contacting someone else for a 2nd opinion — or worse discourages contacting a 3rd party — it is a huge red flag.) 

Excuse the outlandishness of this idea — it is just an idea that needs further refinement. If you are extremely narrow-minded or think “nothing can change/nothing will help” please stop reading now, to avoid reading something that might upset you. You have been warned…

Continue reading

UI Missteps: Form over Function

Don’t get me wrong. The people at MacUpdate usually do a great job of managing and taking user feedback. But even with their careful curation of Mac & iOS apps that receive updates (sometimes numbering close to 100 OS X apps alone in one day), things slip through the cracks. I wasted about 5 minutes trying to figure out why an updated app was not available via one-click update using the built in software updater nor MacUpdate’s Desktop app. After going to MacUpdate, it was only by reading the comment and then hovering above the download link that the answer was clear: the app was a beta, and using the built-in update tools both within the native app & the MacUpdate Desktop App wouldn’t work. Even though I have “show beta/pre-release” unchecked, it still showed up in the MacUpdate Desktop list.

I realized the problem when looking at the comment and the confusion about version numbers used and how Adobe doesn’t distinguish betas with “b” or “(beta).” Then I took a few minutes to write this. The focus is not what MacUpdate did — it is an edge case which reflects more poorly on Adobe. Instead it is a example of what UI designers everywhere are doing to the detriment of both advanced and novice users everywhere.

Making Simplicity Difficult (Form Over Function)

If you accept that the purpose of computers is to make tasks easier to accomplish than doing them without them, then what follows is logical. When the interface gets so polished the labels are rubbed off, advanced features are hidden or removed, and labels are replaced unlabeled/undocumented icons, it leads to problems using an application no matter what type of device the application runs on. Here is my brief comment on that.

I don’t mind clean, nice-looking interface (I strive to balance aesthetics with easy-to-access, powerful features), but don’t let streamlined designs actually slow productivity; whether that productivity is actually getting work done or doing administrative tasks such as updating your software.

This confusion is a clear case of form over function, which is the wrong direction (unless you’re selling soda or commodities…) for computing interfaces to head because it handicaps learning via obscuring helpful, orientating/navigating details and slows advanced users.

If the trend in UIs were to spill over in the real word, we would see street signs replaced with pictures of maps and street addresses removed from the front, and instead only inside each building. Menus boards would have descriptions and prices hidden, until a person opened a flap to read the price and description.

In houses rather than work aesthetics around function, some streamlined houses would only have one control panel that controlled all the lighting, heating, etc. but that panel would be fixed next to the circuit breaker box. If a house had individual light switches, they’d be placed at whim of a designer who never lived or had even been in a house. Some would be oriented at any angle the designer liked and on any surface — some nowhere near the door or on one or both sides of the door. Some switches would glow only when they were off, and not when they are on, and vice versa which is actually happening with electronic switches. All building layouts would depend on the whim of a designer that had no concept of architectural design patterns nor a care about the building’s function.

This current trend toward “flatness” that was a backlash against “skeuomorphic” design of last generation all dance around the real point of GUIs: to make things easier by giving feedback to users that allows them to assess both current application state and orient where they are in the system. The trend is stripping away both of these, making things harder to use, not easier. Sadly, people think simplifying the interface will help users whose learning is being retarded by confusing inconsistent and low-feedback designs. This over-simplification is in fact hurting more than helping. This is because simple is not necessarily a synonym for easy. (Easy things are simple, but simple things are not always easy oddly enough.) Product managers and designers think people want simple, when they really want easy. Making things easy should be the focus. The easier a more complex the task is, the more useful your software.

Making Complexity Easy (Form Follows Function)

Designers should look for the frustrating points and the complex points and make complex tasks as easy as possible — which means removing steps if it can be done without making the user’s knowledge have to ramp up greater than the complex steps.

This is my Menubar. This is easy:

menubar

It is very dense with information. By looking at it you can see with a glance that Bluetooth is on, I’m connected to the network with light traffic, my processor load, my sound volume, the day & date, my current battery level (full) & that I am plugged in, the time, the moon phase, the CPU temperature & CPU voltage draw. I could have the default OS X menubar, but then I wouldn’t be able to see this without opening applications, slowing me down. I often refer to network speeds and CPU load when something seems bogged down. I often check the date and time, and that calendat icon pulls down so I can see my schedule in Fantastical without opening the Calendar App. The functionality is available if I pull down my sound menu is Audio Switcher.

audio-switcher

All these save me time each use. The march of Menu Items and GUI Enhancements I use all take a complex array of data, navigation, and bother of doing complex things and make some of them a click or less away. While this might be ugly to some, it is not distracting and works well. This is my current balance point, but with each stripping down towards “simplicity,” this ease becomes more difficult. Thankfully the developers of iStat Menus, Fantastical, Bartender, Audio Switcher, Moom, TotalFinder, Default Folder X, Alfred and PopCar (among others) see the problem that streamlined interfaces bring. But rather than strip away information, they strive to arrange information in a way that is not overwhelming and give user configurable interfaces to really harness the power of a GUI. These companies (while not all perfect — some have fallen into this hole at least slightly) have UI designers, not artists making flat colorful mystery icons with unpredictable UIs that confuse people calling themselves UX designers.

(I think of myself more as a User/Communication Efficiency type of person, so while the “UX Designer” title sounds fancy, I’d rather be a “User Interface Communication Efficiency Designer” to put the emphasis not of the “experience” of using a product, but on the efficient use of communications media available. Plus, UICED sounds like a term that could be played with. But titles are kind of limiting in a way… so I’ll just be myself. When people ask me my title, I just sum it up to say “IT Consultant” since whenever I actually start to talk tech I notice most people’s eyes glaze over.)

I try to focus on what matters to get work done, so I can get work done with less effort and faster. Anything that gets hinders more than helps my efforts falls out of use. BTW, if you are not familiar with these products, many are mentioned and linked on my Recommended Apps page. You can also check out MacUpdate.com and see the trove of software — most at least decent — that they list. They are good guys, so if you see errors, write them and be nice please. They will get back to you if needed with a personally written reply, which is always worth a star in my book. “When I was a kid several days of Mac SW updates could fit on one page… now several pages might span one day.”

Thanks for reading.

Almost Everything I learned about Teamwork and Leadership, I Learned in Clan Lord

I’ve been threatening to write this post for about a year. I had this sitting on the back-burner for a month and asked for comments from another player also in the IT Admin field. So, without further ado…

Despite the Graphics, CL has real team-building potential

Despite the Graphics, CL has real team-building potential

For the unwashed, Clan Lord is an archaic, sorely out-of-date Multi-player Online Role-playing Game  (MORPG) that has been running since the late 90s. The single world (server) and small population make it feel like a small town, thus all of the current players have the same goal (job). Thus, like any small group with common goals, it is a bit like a company: You have your people in it who are on the ball because they work well in teams and independently, those that only work in teams because they need direction, those that lead group of people in a direction, those that specialize in a subset of knowledge about the terrain (market or technology) all of whom trade their time and risk profit (experience) to advance, and finally those that just show up to have fun. These flyby ‘fun’ people are equivalent to the people who just show up for a paycheck. In the game, one seemingly minor mistake can lead to the death of the entire group.  This necessitates departing (experience and time loss) which is a bit like working on a project  and having it fail miserable because Joe Paycheck didn’t know or care that you shouldn’t have done X.

Considering the parallels I noticed about the in game group and the group of people you work with  day-to-day, I have found several commonalities that I have taken from work to game and from game to work that have helped me navigate real life teamwork, leadership and relationships.

Continue reading

This Week, Last Week, Next Week…

Excuse any typos, but this is a seat of my pants post… I finished up one job last week, which led to time to refactor this proof of concept class while revising other work. Exterior demoes of these proofs get reactions akin to saying, “Wow!” But I feel like Oz, saying “pay no attention to the duct tape and zip ties holding up the curtain!”

When I say “proof of concept” I usually mean, if you look at the underlying code you realize the magic is in the amount of code smell (aka Bad Practices used) — which happens when I just sit down with an idea and just write something that works and best practices aren’t at the forefront. An analogy of this would be an artist sketching a picture quickly to just practice the art and exercise their perception-hand-eye-coordination. Another dev would see this stream-of-consciousness sketch-style coding, and think “that’s crap!” because trying to modify it would be a huge pain. And I couldn’t disagree, because modifying would be a huge job in comparison to writing new code.

However, It is times like these I like to reread this: http://stilldrinking.org/programming-sucks to remind myself that when I mentioned how I hate working with “crappy” code or incomplete documentation. 

Any time I do toss a stone at some crappy code, I get some snarky “this is where the magic happens” comeback, and sometimes even that venn diagram showing my comfort zone outside it. Yeah, guys… I get it. I realize that we are all guilty of it because of workload or time constraints — no one is perfect. There is only so much one can do in one session, even if that session is a solid 13 hours (which I have done before). So, I can either throw stones or TRY to develop better sketch practices with each sketch. This is what I have been doing the past week. I will write a class with comments, DI, patterns, etc. Then look back and see where the comments/structure broke down or when things got vague or messier. Things are improving, but they aren’t where I would like them to be.

But, does it really matter if my on-the-fly code is written poorly as long as it doesn’t crash? Probably not to anyone that might use it, but oddly I can’t get a voice out of my head that says this is wrong. If I want to see better examples from others, I should practice what I preach, and only release the refactored stuff, and things that don’t set off any code reflection warnings. Last week I only had the energy to write 3 base classes, each one had at least 2 or 3 code smell warnings. This week I refactored and got fewer warnings, but then the limits of the docs smacked me in the face, and things broke. I suppose this is part of the growing pains of learning how to use new tools. And then I bang on the problem until I either revert to a smell-but-working version or figure out what the documentation meant. This is when I re-read this: http://stilldrinking.org/programming-sucks so I don’t feel so bad about why I am not getting it.

2013 in review

This past year saw another significant increase in page hits, which is cool in some respect. However I value interaction more, and comments are few and far between. Still people seem to care mainly about music and bluetooth headphones. The great thing is, BT headsets are now in the realm of “very affordable.”

FYI, the prior post generated a few “corrections” as to the song title of Squeeze’s “Another Nail For My Heart.” After a short discussion, and seeing both versions in print, with most favoring the one I thought to be inaccurate, I decided to write the songwriter to ask because it was starting to bother me. After listening to that song for a good 3 decades, I was convinced it was a mistake someone made, who was not familiar with the song. The lyrics said different, while the old saying says something else. It would have been natural for someone, early on, to favor the familiar saying, instead of the more subtle lyric. I alway interpreted it as if the “nail” was either a love song or a drink, or both. Here is a guy heartbroken over a breakup, drinking his sorrows, while the piano player sings  songs, each love song, another nail for the writer’s heart. This is conjecture, unless the songwriter weighs in, but it is my interpretation of it.

I figure, you can strive to be right or you can strive to be accurate. Favoring the former will mean less of the latter, whereas striving for accuracy will often net you being right more often. I was well prepared to be wrong, learn yet another small thing and wait a week while whomever intercepted the message, hopefully passed it on. To my surprise, about 5 minutes later, the songwriter, Chris Difford, answered, and wrote back:

Thanks for the email, it is indeed – for my heart…..

its been many years and it has chopped around on set lists, but from the original this is the real title

many thanks.

Cd

That, in and of itself was pretty damn cool. Sometimes I love the Internet, and being able to reach out and ask someone whose songs you have been listening to for over 30 years a question and get a fast as light answer, definitely falls within the realm of cool. By the way, I will leave readers with my summary, and a new axiom:

You can strive to be right, or you can strive to be accurate, but trying to be accurate instead of being right will get you both more often.

Someone probably already said this. If not, this one is mine. That, and I appreciate people who actually take the time to look things up — unfortunately, in the above case, the info is mostly wrong. Thanks for reading.

Continue reading