Veropedia and Information Ethics
By Jacob Cohen | October 29, 2007
There is a new online encyclopedia called Veropedia, which is being developed by selectively taking content from Wikipedia, cleaning it up, and securing it in a non-editable format.
The idea seems to be that Wikipedia articles are often incomplete, and the accuracy of the information is not strictly controlled, since anyone can submit an edit for an article.
Veropedia is a for-profit endeavor that supports itself with advertising revenue, I believe this creates two ethical conflicts.
First of all, they are not creating the content themselves. They are taking what has been contributed by the community, sprucing it up, and fixing it in place. If they claim the derived work as their own, that would be deceptive. If they give credit to the original author, they’ve removed that author’s ability to make corrections and updates to the content. If people compare the Wikipedia entry to the Veropedia entry, and notice any discrepancy, how are they meant to react to that? Is the original author less correct because Veropedia is making claims about the verified accuracy of its information? Or is Veropedia less correct because their article is not receiving the latest information from the author?
The second issue is that they are supporting themselves with advertising revenue. This is risky, because there is a potential for a conflict of interest if the articles contain information about the companies that are paying to support the service. How can we be assured of the intentions of the people who are validating that the articles and information are accurate?
I think for an encyclopedia to be accepted with a clear conscience, it needs to either follow the Wikipedia model, or it needs to bite the bullet and support itself with its own sales, and research and create the content itself. I think it is pretty questionable to take the content created on another service, pack it up and seal it, give it a stamp of approval, and then take advertising revenue to support the effort.
As far as I know, there’s nothing wrong with Veropedia’s approach from a legal standpoint, the content they are using is all available for them to do so. I just don’t think we can necessarily trust the intentions, and consequently, I am not sure the product is more deserving of trust than Wikipedia.
Topics: General | No Comments »
Understanding Performance Trade-offs
By Jacob Cohen | August 30, 2007
I think most programmers these days are fairly aware of the performance trade-offs of using an interpreted or bytecode-based language like Perl or Java, compared to a compiled language such as C or C++.
There is also little doubt that we now have more computing power available on the desktop than ever before. The performance losses that used to argue against using languages like Python, Ruby, C#, Perl, or Java, are now virtually impossible to notice to the end user.
Jeff Atwood writes, in an article about the pitfalls of C++:
C++ is fast but unforgiving. It was an appropriate solution for an era of limited computing resources. But we’ve long since left that behind; we live in an era of abundance. We have more computer power than we possibly know what to do with on the desktop. Even the naive solutions for most computing problems are “fast enough” these days. Computers get faster every day, but programmers’ brains, sadly, do not. It’d be a waste not to trade some of that abundant raw power to make things easier on us. It’s time to evolve up the one trillion dollar programming pyramid.
I think that this is a dangerous mindset. While a naive solution may be “fast enough” for one problem, it can quickly become “far too slow” for another. Algorithms and data structures must still be chosen wisely, even in this era of abundant computing power. As I’ve discussed before, there are often simple ways to achieve vast improvements in the performance of an algorithm that allow it to scale far beyond the naive solution.
The naive solution to a problem is certainly attractive in terms of the ease of implementation. However, we need to be careful not to be overconfident in our abundance of computing power. We certainly have enough spare power in today’s desktop machines to make light of the performance differences between C++ and Python for a standard user application. However, no amount of computing power can make up for an algorithm that scales poorly with the size of the problem to which it is applied.
Topics: General | 8 Comments »
Stealing Focus
By Jacob Cohen | August 30, 2007
Applications are sometimes slow. In fact, the longer you use an application, the slower it becomes. Or rather, the application stays the same, and you get faster at using it, so it seems slower than it used to.
Perhaps you no longer wait for slow web pages to load, and instead you load them in a separate browser tab and switch to them when they have finished loading. Maybe you don’t wait for your e-mail client to prepare a folder for viewing, and switch to a different application while that is happening.
The more you do other things instead of just waiting for a slow application to finish, the more you see of a new problem that can happen on Windows systems. The problem of applications stealing focus.
Some of the applications will, when they have finished whatever slow task you have set them to, focus themselves in front of whatever else you were doing. Apple’s iTunes/Quicktime updater is particularly egregious about this, it will refocus itself after every step of a process that has no reason to ever be in focus. It should happen in the background. Microsoft Outlook is another. If you load a large folder and it takes a moment to prepare the view, it will steal focus back once it has finished.
Why is this behavior allowed? Applications already have a perfectly reasonable means of letting you know they need your attention again - they can flash their taskbar tab. Better yet, maybe the designer of the application should realize that they have no real reason to demand the user’s attention, and patiently wait for the user to switch back to the application.
Topics: General | 11 Comments »
New camera
By Jacob Cohen | August 23, 2007
A while back, I wrote that I was considering a digital SLR camera. As it turns out, my wife surprised me for my birthday with a Canon Digital Rebel XT!
This camera is great. The shutter speed is incredible compared to the snapshot cameras I am used to. I can take pictures of our dog running around without the shutter delay and motion blur I used to get with the old camera.
For comparison, here’s a picture of my new camera, taken with the old Powershot A70:
And here is a picture of the Powershot A70 taken on the new Canon Digital Rebel XT:
The new camera has much nicer contrast and color saturation, and it doesn’t have some of the ghosting and blurring effects found in the pictures from the A70.
Topics: General | No Comments »
A better idea
By Jacob Cohen | July 20, 2007
Back in March, I played with the idea of adding advertisements to the site to help support its cost.
Now I have a better idea. I’ll just ask people to help support me on the Seattle 3-Day walk in September, which benefits Susan G. Komen for the Cure to fund breast cancer research and treatment.
So if you like this site, please make a donation on my personal 3-day donation page, which can be found here: http://www.the3day.org/seattle07/jacobc79
Note: none of this money goes to me. I’m perfectly happy to run this site for free if people will donate to charity in support of it instead.
Thanks for reading.
Topics: General | 2 Comments »
Simplicity of Important Information
By Jacob Cohen | June 27, 2007
At the risk of seeming like I don’t write a new blog post until Jeff Atwood creates a post on his Coding Horror blog that piques my interest, well, that’s exactly what happened again. Oh well.
He writes in a recent post on end user license agreements that they are all effectively legal mumbo jumbo, and often contain clauses that most people would never agree to, but end up just clicking the “Accept” button anyway because honestly, who can be bothered to read that whole thing?
I think this problem isn’t limited to EULAs. It is also found in the fine print on television commercials, product packaging, and the privacy policy of many web sites.
First, however, let’s consider the EULA. It is often lengthy, with some sections written in all capital letters, and often must be viewed within the confines of a small scrollable text area inside a fixed-size dialog box. What gives? People are fairly adept at scanning a large area of text to identify important sections (particularly if the text makes judicious use of capitalization and font styling), but by creating such a small viewport, it effectively prevents this entirely.
(I’m not trying to pick on Konfabulator specifically, but it was an installer I had handy to get a screenshot. This presentation of an EULA is typical.)
But this problem isn’t limited to EULAs. Consider the privacy policy on a web site. Typically, these are designed to inform the visitor about what sorts of information the site will collect, and what it will be used for. Like the EULA, these are often long, though they do not typically suffer from the same small viewport problem. They do, however, sometimes conceal some information to which an average visitor might object.
Take Collages.net for example. It is a photo album site that allows photographers to upload digital images, and the album can be shared with other people online. However, to view the album, you have to enter your e-mail address. This struck me as a bit odd, so I viewed their privacy policy to learn why. After some poking around, I found this clause:
In addition, we may periodically make such information (except for credit card number and expiration date, unless you consent otherwise), including aggregated information, personally identifiable information with third party businesses and affiliates for the purpose of direct mail, email marketing and telemarketing.
They do provide a way to opt-out, but unless you read the whole policy, which is about 3 or 4 pages, you would not see it.
Why are we so stuck on the idea of making information like this complex and hard to find? I much prefer programs and sites that make it simple. Plain, straightforward language that says exactly what you need to know.
Why do we always need disclaimers that mention that the software doesn’t provide warranties of merchantability or fitness for a particular purpose? When did it become the case that anything that wasn’t specifically mentioned in a disclaimer or a EULA was automatically assumed?
I think software vendors and web sites need to make an effort to simplify these lengthy documents and distill them into something that is easily intelligible to the end user, and that conveys all the information they need to know.
Topics: General | 2 Comments »
Last.fm gets it right
By Jacob Cohen | June 21, 2007
I recently discovered an online music service and community called Last.fm. Like Pandora, it provides a way to find music that you like, based on other music you like.
Pandora’s concept is to be able to determine what music sounds like, and find other music that sounds similar. Last.fm’s concept is more social networks centered, using tags, recommendations, and listening habits to figure out what other music you might like based on what you’re listening to.
One of the things they do right is you can get started right away without signing up or downloading anything. This is what drew me in in the first place. I could see the benefits of the service without having to sign up beforehand.
To get an idea of how easy this is, I typed in one of my favorite artists, “Nightwish”, and it came up with a tag cloud that included “female fronted metal”. I clicked on that and it generated a radio station of songs that had all been tagged “female fronted metal”. This is basically my favorite genre, so it’s almost like having a custom radio station that plays mostly songs I like.
Here’s an example of a widget the site created for me to embed wherever, that lets people listen to music based on my music preferences. Pretty cool, but apparently the music isn’t always available to play due to radio broadcasting laws. Hrm.
|
|
Topics: General, Tech | No Comments »
Agile vs agile
By Jacob Cohen | May 25, 2007
Agile software development, with a capital A, is a collection of software processes geared towards minimizing the risk of changing requirements. Typically this is accomplished with short timelines, an emphasis on delivering something rather than large up-front design, a tendency to eschew large and lengthy meetings, and so on.
This type of software process has gained a lot of popularity in recent years, and now there are seminars, books, courses, experts, consultants, everything that essentially makes an entire industry around the Agile software process collection.
Strangely enough, the people who use and evangelize Agile software methods seem more concerned with software process than people who use non-Agile methods. They hold heated discussions on mailing lists about why certain Agile methods are better than others, and how any failed project was just doing it wrong.
I find it strange that there is so much emotional investment in something that is supposed to be the antithesis of heavyweight software development processes.
Perhaps it has something to do with the name. If you’re not using an Agile software process, maybe that implies that your software development isn’t agile. That is, it’s cumbersome, slow, and inflexible. Is this necessarily the case? I think there is a difference between being agile in your software development, and using an Agile development method.
Perhaps the reason people are hesitant to say anything bad about their experience with an Agile method has more to do with wanting to avoid seeming un-agile, than with actually believing that the software process is perfect.
I think developers should be agile in how they respond to changing requirements. However, this doesn’t require an emotional investment in the Agile software methods. If you’ve tried something and it isn’t working, try something else. Isn’t that what agile is about?
Topics: General | 2 Comments »
Livejournal Has Massive Usability Problems
By Jacob Cohen | May 21, 2007
I wanted to post a comment on a friend’s Livejournal blog, but I had forgotten my password (I don’t use LJ very often). So I tried to send myself the automated password reset e-mail. I got an error:
[Error: Database handle unavailable at /home/lj/cgi-bin/LJ/User.pm line 364. @ w72]
This is problem number one. Why can’t they create a saner error message than this? I tried again, and this time it sent the e-mail.
This arrived very quickly, and I was able to easily reset my password. Next, I wanted to go into my account and change my password from the auto-generated one to something I would remember. So I go to the password change form, enter the info, and hit submit. It recycles with an error message telling me I can’t change my password until my e-mail address is validated. This is usability problem number two. Why show me an option and have me fill out an entire form if it knows beforehand that it won’t work? Why is this even a requirement? I was able to reset my password with a non-validated address.
So I go through the steps of validating my e-mail address, which is basically sending an automated e-mail that is extremely similar to the password reset e-mail. Why didn’t it validate my address when I reset my password?
Once my e-mail address was validated, I went to change my password once again, filling out the form again. I hit submit, and was greeted with the same database error as before. I try one last time, and now I get this:
There was an error processing your request: Your IP address is temporarily banned for exceeding the login failure rate.
This is horrible. More than half of the “login failures” were caused by their own software’s instability or unclear requirements. So now I have to wait some unspecified amount of time before I can try again, and I still haven’t been able to post the comment, which was all I wanted to do in the first place!
Topics: General | 2 Comments »
Thinking in DFS vs BFS
By Jacob Cohen | May 14, 2007
The concepts of depth-first search (DFS) and breadth-first search (BFS) are usually used to describe an algorithm for visiting nodes in a graph or a tree structure. The key difference is whether you visit all of the nodes nearest to you first, then begin radiating outward from there, or whether you continue as deep as possible along a given path first, and backtrack only when you can continue no deeper.
A thought process can be represented as a sort of graph. If you think of one thing, and that brings to mind something else, it is like forming an edge between the two nodes that represent the different thoughts.
If thoughts are like a graph, then what is the difference between a depth-first search and a breadth-first search between thoughts and memories? Depth-first search is what happens when you make several intuitive leaps from one thought to another. For example, if someone says, “I need to go get this film developed,” and you pick up on the word “developed,” you might then think “developer,” which could lead to the famous Steve Ballmer “Developers, Developers, Developers” video, which makes you think of Microsoft, which makes you think of Bill Gates, and finally you say “hey I heard the Bill and Melinda Gates Foundation donated a lot of computers and money to the computer science program at Stanford.” Then you’d get a strange look because you were supposed to be talking about cameras and film. This is depth-first search in the human thought process.
What about breadth-first search? This is thinking about an idea and coming up with a list of all the thoughts it triggers. You have to be careful not to follow down the path of any of these thoughts, or you’ve begun depth-first search. In the example above, if someone mentioned getting film developed, you might think of camera stores, or film developing solution, or remembering to rewind a camera before taking the film out, or the difference between 24 and 36 exposure rolls.
How often have you thought of a bookmark you had as being “near the bottom” of your bookmarks list, and when you’ve added enough bookmarks that this is no longer true, that bookmark becomes much harder to find? Mentally, that bookmark’s value was secondary to the notion that it was “near the bottom” of the list. It has forced a DFS traversal on what is meant to be a breadth of information.
There are many applications that choose their own convention for where to access their options and settings. For example, in most Microsoft applications, the Options dialog is found in the Tools menu. In Photoshop, you find Preferences in the Edit menu. In Wordpad, you find Options under the View menu. But how do you find it if you don’t remember where it is? You search menu by menu looking for it, which is essentially a BFS traversal of the menu tree.
So what does this mean for interface design? It means that as we become accustomed to using an interface, our memory on how to do various things can be triggered by familiar UI elements. This causes us to make the mental leap to the process by which we accomplish whatever we’re trying to do. We remember processes and UI habits in terms of DFS, but we learn them by experimenting in BFS fashion.
Topics: Design, Tech | 2 Comments »
