As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to know what do you think about adding captcha mechanisms to registration forms?
I notice that many sites don't use captcha mechanisms in their registration forms(examples: http://djdesignerlab.com/2010/04/14/25-cool-sign-up-and-login-form-designs/).
I would like to open this topic to see what people thinks.
I always thought that we should make our forms as secured as possible, but from another point of view there are many users out there that don't really have to much patience to fill a captcha at a registration page.
-Do you think adding this mechanism to a registration page can drastically drop the amount of registered users at long term?
-How dangerous can it be not including this mechanism at a registration page?
I setup captcha on my system for one main reason: To know that the user who register or is registered is actually human. Don't forget that captcha is not only used for registration and/or login security checks. SO, for example, have captcha if it senses that there's too frequent edit on the same question/answers in a very short time span. Captcha, in this case, is a check to see if the editor is human instead of a robot.
In essence, you have to make a good decision of where you will like to use captcha (if you're planning to use it) and how will it serve for your purpose.
Hope this helps.
I can't stand captcha's at all. I understand the need for checking against bots, but why should the legitimate end user have to pay the price in reading obfuscated words... that's my personal opinion.
I have seen some sites actually ask basic questions such as, "The colour of the sky is: " provided with a textbox and clue to the word length. Its a bit more on the fly but to be honest I have had no problem getting the right answer with the ones I have seen.
I refuse to implement it - its a big 'F U' to users. The only exceptions are those where numbers are required... these are much better as there is no casing involved, half the time with letter based captchas you can hardly tell which letter are uppercase or lowercase.
We've come a very long way in web accessibility, captcha's are sending us in the wrong direction. Recaptcha does serve a purpose I agree, but its still a captcha.
Danger is one thing, but the flood of SPAM you will get is another. I have seen situations where a commenting system was rendered useless because of the SPAM that was being added.
There are definitely issues with CAPTCHA's beyond simple inconvenience. There are accessibility issues with a lot of them. I prefer RECAPTCHA which does a really nice job of handling accessibility while performing a service at the same time.
There are other options out there, Akismet is a verification tool that does not require user input. I would recommend looking at that if you are trying to avoid the manual verification process.
I think it's a case by case situation. If your site is public and popular and bots could gain a financial value for a clever programmer by posting content to your site, then the captcha is the way to go.
If you find that your site does not get much traffic or it is on a private network, then there is no point to employ a captcha.
I would suggest going without it at first, then pull it out of your tool belt if spam becomes a problem.
Me and a few of my fellow small publishing friends created a private database to pool IP addresses and netblocks of known spammers. Some of us have removed our recaptcha integration in favor of backend IP check. Some backlink spammers are getting through, but its slowing down as the database gets larger. We've opened up the api so others can give it a try: http://www.spamerator.com
CAPTCHA? Fine. Set it up. But please make it human-friendly, like this one:
The letters are clear, big and readable. And if you don't use images, I have implemented a base64 one in addition.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
AT the moment, the site I look over sends an activation email to new members which have a link they must click to activate their account. While this seems like a good idea, it has many faults such as occasionally the email lands in their spam/junk folder and its yet another step the user has to do.
I was try to make it easier for users to join and activation seems to be the biggest hurdle. We have put this in place to avoid spammers and scammers and it does work. I don't want to go for the 'moderation' method either.
Any suggestions?
One alternative is to do it the the way StackOverflow does and create an account by linking it to their gmail account (or similar) automatically. Theres minimal hassle to the user then and its a valid way of attempting to ensure that the user is legitimate
I think at this point, email activations and CAPTCHAs are so common, the users are used to it. I wouldn't worry about email activations, but I would warn against overuse of CAPTCHA. I'm thinking of one forum I checked out recently which insisted on an image and logic CAPTCHA on registration, and then again for each of your first five posts. Considering the image CAPTCHA was the same generation each time and the logic CAPTCHA was identical each time, I think it was overkill.
I'm guessing that by the "'moderation' method" you mean actually have moderators that watch over the site and ban spammers. I can understand your dislike for such a system, but an alternative that a lot of sites use is peer moderation (e.g. StackOVerflow or Slashdot). This still means that spam gets posted, but it usually gets flagged or otherwise modded down so far that no one will ever see it.
Another tactic is a reputation system that requires a certain level of rep before one is allowed to post links. StackOverflow has a system like this as well (you can't even comment before you reach a certain level of reputation). This can be a little annoying at the beginning, but it's definitely effective at eliminating spam.
And as already mentioned by others, CAPTCHAs are probably the easiest anti-spam technique to implement. There are many libraries and APIs out there for generating CAPTCHAs, and you can even put the tests to good use by using reCAPTCHAs to help digitize books. The drawback is that automated CAPTCHA-deciphering algorithms are getting better and better, and the spammers without the ability to implement them can often farm the work of solving CAPTCHAs out to 2nd/3rd world workers.
Whatever method you choose, there's going to be some level of inconvenience for the user, but most of the common techniques are readily accepted by users and worth the trade-off to eliminate spam.
The most used way is a verification mail + captcha, because usually emails from unknown sources aren't sent to spam folder. I tried this way with Gmail and Hotmail and both are working perfectly.
You can also use other systems such as using the OpenID (I think this is a very good way), Gmail account, Facebook acccount etc...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Has using an acknowledged anti-pattern ever been proven to actually work in a certain specific case? Did you ever solve a problem or gain any kind of benefit in one of your projects by using an anti-pattern?
My understanding of the "anti-pattern" concept is that it encompasses solutions that have drawbacks that only reveal themselves over the long term. Indeed, the primary danger associated with a lot of them---like writing spaghetti code with loads of global variables and gotos every which way, or tossing exceptions into the black hole of an empty catch block---is that they're seductive because they provide an expedient solution to an immediate problem.
EDIT to add: Because of that, sometimes you do derive benefit from these anti-patterns. Sometimes your calculation that you're writing throwaway code that no one will touch again is dead wrong and you wind up with maintenance programmers slandering your heritage and sexual hygiene, but other times you're right and that crummy shell script that's held together with baling wire and spit does the job you intended it to do and is then blessedly forgotten, saving you the considerable time and effort of putting together something decent.
Anti-Patterns are still so widely around just because they solve a particular problem (while creating 10 new ones). Also known as workaround. But how do they say? Nothing lasts longer than a makeshift.
In fact I believe we'd all be jobless if things had been done right from the beginning.
The biggest problem that it has solved in my experience is launching a new application.
When the dev team has scoped the new application thouroughly, the timeline to implement the correct solution is usually too much for management to bear. Therefore, oftentimes, you code to meet the timeline, rather than "correctness" of the solution to get to the launch date, (but have others coding the "correct" solution for the next rev), making it essentially "throw-away" code.
One software anti-pattern is Softcoding, also defined at the daily WTF. Softcoding happens when programmers put material that "should be" inside code into external resources.
I'm working with software that some might say is suffering from softcoding. External files drive the software. Those external files are a micro-language: they must be compiled to XML before the software can use them. This micro-language has its own tools.
But softcoding is always in the mind of the beholder.
Having the material in a micro-language with its own parser has made my life easier. One data source can generate many different outputs: In addition to the version that the main program uses, I am able to extract information into HTML, .csv, and other formats that our customers want. Other programs can generate code in the micro-language, making automation easier.
In our case, softcoding has been a useful pattern, not an anti-pattern.
There is a reason for calling it a pattern rather than a law.
I would surmise that almost everyone has at least one example of a place in code where exactly the wrong thing was done, and it turned out better in the long term than the "right" thing would have.
And a far longer list of examples of anti-patterns causing trouble.
I have used magic pushbuttons a number of times, out of ignorance or laziness, and sometimes it actually worked out just fine, and it turned out that I did not need the extra abstraction of proper MVC.
Duff's Device utilizes the Loop-Switch Sequence (AKA For-Case Paradigm) anti-pattern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When deciding whether you are getting involved in a fairly big open source project in order to contribute to its code base, how significant are the project's issue tracking facilities (i.e. tracking of bugs & feature requests) for your decision to contribute or not?
There are still many non-trivial (huge code base) open source projects out there, that don't formally do issue tracking - and while some contributors may indeed still do this privately in the form of miscellaneous "ToDo" lists, I have personally found the lack of availability and established use of issue tracking to be a fairly reliable indicator for a lack of organization, structure and overall project coordination.
What are other people thinking?
I would say it would be a fairly significant factor.
An open issue tracking system is one component of what I would call having an 'open development process' - where anybody who is so interested can see the developers' decisions as they are being made, and contribute to the discussion.
Some projects don't really have an open issue tracking system (or a good one) but still have publicly visible discussion lists, maybe an IRC channel where there are always people on, maybe a forum/bulletin board, etc. In my opinion such projects are still fairly attractive in terms of contributing to them.
What I have personally found is that while I work with very many different open source projects out there, I don't ever really become part of a larger group. However I do find bugs and would like to report them and would like to find out if the issue was found before, and when and if it is going to be fixed.
For myself personally, an open bug tracker or mailing list where I can shoot a one-off email to notify people of the bug is better than having to signup for the mailing list or register for the bug tracker. I already have enough accounts all over the place, I don't need yet another one for the piece of software.
So the friction involved in reporting a bug is definitely an issue, also being able to view the status of bugs and having them be searchable is a big help in determining on whether or not I will report my issues to the project or not.
So yes, open issue tracking, easy to use, easily visible (digging through a page for 20 minutes is not my idea of fun) and best of all with as little friction to get a report of a feature wanted/bug in.
A number of projects that I'm involved with still do everything on the mailing lists. If a bug comes in (and gets confirmed, and can be fixed) its put in some kind of BUGS file within the repository. As things get fixed, the entry in the file is noted.
Not my preference, but its what other contributors are accustomed to and like. It could be that someone doesn't want the hassles of hosting the bug system, dealing with the SPAM it might attract, etc. Could it be that the project doesn't get very many bug or feature requests?
The real question of 'should you' really revolves around the code, no? Or how much you could learn / teach by working with any particular group? If you begin contributing and show yourself to be friendly and useful, you might meet no resistance when suggesting something like trac or bugzilla.
The only thing that would make me consider steering clear of any given project would be a total lack of any kind of version control. But, even then, I'd have to weigh what I'd be given up against the hassle of managing patches with racy merges.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have asked a few developers who produced software they no longer maintain or let die, why they don't open source the software and let other developers take it forward and enhance it. Or at least not let it disappear.
Most of the excuses were about the quality of the code. They don't want to open source because they are ashamed of what they have coded.
In my opinion, if the software works, people are downloading it and using it, that says enough about the software. No one is proud of their own code. If anyone looks at their year old code, you surely decide you can do better now. I have used some good software no longer exists. I find it this to be a waste of good resources.
Why would some developers prefer to let their software disappear instead of giving it to the public? One reason I can think of is that they used someone else's IP and they don't want to be exposed. Should developers be encouraged to open source their software if they have no intentions of profiting from it now or in the future?
If someone really wants to release the code but are ashamed of it, the rational solution is to remove all traces of their authorship from the source code, then either release it into the public domain, or assign the copyright to someone else.
That aside, there are all sorts of possible reasons for an author not releasing source code:
Maybe the code really is crap and the author doesn't want a potential future employer to associate him/her with it.
Maybe the author is unduly sensitive about (possible) criticism from his/her peers.
Maybe the author thinks the code is not worth the effort of saving, and is trying to stop other people wasting their time on it.
Maybe there are potential IP issues that the author doesn't want to spend time sorting out:
some open source code might have been copied without proper attribution or under the wrong license,
some closed source code might have been copied,
some patented method might have been used. (Aside: can anyone ever be sure that their code doesn't uses a patented method? No!)
the author really cannot remember what short-cuts he/she might have taken N years ago ...
Maybe the code contains secrets that the author doesn't want to reveal:
maybe it doesn't do what he/she claimed it does in some research paper, or some such
maybe he/she thinks it might give competitors (e.g. other academics) an advantage to see the "secret sauce" techniques his code uses.
Maybe the author dreams that some day he/she will be able to sell the code for big pots of money.
Maybe the author dreams that some day he/she will find the time and energy to fix the code, release under an open source license and become as famous as Linus. (Yea .. that Linus!)
Or maybe the author is simply just not interested, and the "I'm ashamed of my code" excuse is just a ploy to make you go away :-).
Some people really might not want their code to be criticized and don't feel like cleaning it up. It is somewhat legitimate though I agree if does prevent useful code from getting out to the community. It's not prima facie evidence that they are using IP that they shouldn't though.
Maybe because open a software's code demmands some effort they're not willing to spend.
No one is proud of their own code? Don't believe you.
We will encourage you to develop the
three great virtues of a programmer:
laziness, impatience, and hubris.
-- Larry Wall
I can understand where your coming from. The software works and that's what really matters. I can also understand where the developers come from. Many programmers develop bad habits while coding (ie. not commenting). I'm guilty of this myself sometimes. In my opinion, I don't think this should limit them to keeping their applications closed source. If you open your source, you open the doors to all new sorts of possibilities. If your not going to work on a certain program anymore, why not release the source? People can take what you know, apply it, make it better, and ultimately keep your application up to date and better than before. Overall, developers should be more open about releasing their source code, especially if no profit is ever intended.
I can completely understand this.
I wrote some software ten years ago for a volunteer organization. They are still using it and it 'works'. But it is ugly. I know so much more now about how to design software. It is painful to even have to make updates and changes to it. I'd love to take some time to clean it up, but I just don't have time. I don't really want anyone else to take over the project because I am embarassed to have my name associated with the code -- even though my name isn't actually in the code. It still reflects on me and even though I may know better now.
Logically, I know better. It is stupid to think this way. But I can't overcome the psychology. It is very real and it is a tough dilemma. I wouldnt assume issues with IP or hidden motives.
I have answered the questions posted, in order. Yes, these are opinionated.
[Do you have this as a study somewhere? It would be interesting to see. Just vague references and quantifiers aren't very exciting.]
Perhaps the code was written for fun, learning, work-for-profit at the time, because "it could be done", or for some other motivational reason. It served a purpose; perhaps the purpose is gone -- as well as the incentives behind. It takes effort to find old code, publish old code, and answer silly emails or questions about old code. (And for some, it takes effort to not care about what others think.)
I would be hesitant to jump on the idea that the code kept hidden "violates IP". This is an unfair and unfounded assumption without better proof.
Encouraged? Perhaps. Forced? No. Code is a creation and, like any art, is is a product of the creator. Unless they have alright assigned away the rights, it is the authors work. Perhaps it is deemed to be awful and forever buried away -- so be it. The same happens to other forms of art all the time.
I faced this recently, and concluded that putting the code out there and making it discoverable can be just a first step. If nobody takes an interest in it, you haven't lost anything, and if you start to accumulate a user base you can always improve the documentation and code quality later.
I think people understand the resource constraints involved with software development, and being able to make and explain tradeoffs intelligently is more important than necessarily investing all the time up-front to write 100% good smelling code. Sometimes you need to expedite -- that's what refactoring is for!
I think it may be because the developer think that the software is not really dead and he/she can restart writing and using it in the future.
But the really question here is: Is the effort of releasing the source under open source going to help other people? Sometime the app is just too localized or maybe poor documented, and the developer think it is not helpful enough. It may be a hard to maintain a opensource project (you gotta document it, control it, patch it, etc).
Also, the app could have been using some proprietary code (code that was developing when you
are working for someone else) and he/she cannot release it without being suit in law.
And last, but no less important, Are the developer going to be happy when somebody criticize their code? I think no one likes that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not a usability specialist, and I really don't care to be one.
I just want a small set of rules of thumb that I can follow while coding my user interfaces so that my product has decent usability.
At first I thought that this question would be easy to answer "Use your common sense", but if it's so common among us developers we wouldn't, as a group, have a reputation for our horrible interfaces.
Any suggestions?
Source: http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
Read Don't Make Me Think by Steve Krug. It is a great starting point, and an easy short read.
EDIT: This is mainly for web usability though, but it would still be a good read even if you are doing rich clients.
Just two things, really:
"A user interface is well-designed when the program behaves exactly how the user thought it would" - quoted from Joel Spolsky's User Interface Design For Programmers
Put your designs in front of a user. A real end-user is best, but for lightweight, rapid feedback, you can't beat hallway usability testing i.e. grab a co-worker.
If you remember Joel's advice and make sure you get feedback on whatever you do and act on it i.e. iterate, you'll not go too far wrong. And I would echo the recommendation for Steve Krug's Don't Make Me Think - it's probably the best work-related book I've read, bar none, and is just as applicable to desktop software as websites.
Hope this helps.
Don't make things work in a different way than your users are expecting (i.e. breaking the "back" button when using Ajax in web forms
Follow the K.I.S.S principal
Really, any rules someone posts will be a variation on the theme:
Don't Make Your Users Think
"Don't Make Me Think" has already been posted, see also
Design of Everyday Things and Designing with Web Standards which are also great for light usability reading.
Avoid modes. It's frustrating to a user when input works sometimes but not others, or does different things at different times.
The single most important piece of advice I'd give someone is to work on the UI first. Pen and paper and all. That way, you won't subconsciously couple buttons to functions, input fields to variables, etc.
The best UI might be a pain to code, and if your backend code is mostly written, it will sabotage your thinking.
Other than that, I'd point to Apple's Human Interface Guidelines. Of course, if your platform is not OS X, take the OS X sections with a lot of salt. What works in OS X might not work on Windows. You should embrace your platform's idioms.
OS X stuff aside, that document has some pretty good starting points on the fundamentals.
Here are some simple rules:
Fewer clicks are better.
Frequently used features should be easier to find.
Features for "advanced" users can be harder to find than the ones above.
Think about the number of mouse/keyboard clicks it takes a user to get to something.
PS - please don't tell the Microsoft Office 2008 people about this; the poor little guys would cry themselves to sleep tonight! :)
Think about the users that will use your app. Why are they using it and in which context?
Will the majority be pro users that know the domain in which the application is used and use the app a lot? Then don't be afraid of adding a lot of data to the screens as long as it arranged logically for users (normally that is not in alphabetical order :-). Think trade screens for stock borkers or airplane cockpits.
Are users occassional users? Keep it simple. Avoid context switches (keep all/as much as possible of necessary data for a task on the screen at each time). Don't break expectations of how gui widgets normally work. Design for failures.
Anything in between? Allow users to grow in the UI. Track usage so you can later determine where users seem to spend the most time so you can improve the most used areas of your app.
Test your app on friends and colleagues (the corridor test) to see if they are able to use it efficiently.
That's a start.
I suggest to read these blog posts from the Enso creators.
Of course they repeat guides/ideas/advices from books such as
The Design of Everyday Things and About Face, but nevertheless, the posts contain quite a few insights and (IMO) they are a good read.
What information does your user need, put that on the screen and nothing else. If you cannot define what the user needs - get another user.
Remember that your application will be one of many the user will have to deal with. Don't do things just to be different or kewl. Don't come up with unusual graphics, behaviors, terminology, or interactions. Use the standard OS controls, conventions, utilities, and behaviors.
Let your app interoperate with other apps; allow cutting and pasting of data, save your data in formats other apps can read, and allow importing data from other apps instead of using your UI.
If you are making a desktop app, do not try to take over the user's computer. Leave the user's Documents folder, task bar, and application preferences alone. Don't change anything already installed on the computer. Allow scripted or command-line interactions.
If you're making a web app, do not try to take over the browser. Do not try to subvert the standard menu bars, history, layout, or fonts. Allow the user to change the page using Javascript.
(1) Common actions should require as little effort as possible and should be obvious; on the other hand, actions that are rarely needed can be require a lot of steps and can be hidden behind menus and dialogs. To be able to do so, you should always describe what the user will want to do with the application by listing use cases.
(2) A UI should be selfdocumenting. The manual should be integrated in the application's dialogs and menu's, as users don't read separate manuals. For example, the keyboard shortcut should be shown in the menu item representing the action it is associated with.
Provide keyboard shortcuts for power users (even if it is as simple as "hit enter to search")
Don't put too much on screen at once.
If you pop up a messagebox, your users generally won't ever read it.
In addition to the other recommendations here, I'd recommend Designing Interfaces by Jenifer Tidwell as a good way of becoming familiar with UI conventions.
Also, The inmates are running the asylum By Alan Cooper is excellent for providing an insight into how to approach interaction design.
A good follow on to Don't Make Me Think is Robert Hoekman's Designing the Obvious. It's more focused on web applications, as opposed to web sites like in Krug's.
Simple is better than complex
Complex is better than complicated (eliminate 'nested ifs')
Intuitive (good elements needs no explanation)
Follow the convention (for example, underlined means link, red means error, tab goes to next field, etc.)
Use semantics to apply the logic (header reads first, paragraphs next)
whitespace is important