Bear my ignorance please!
I always believed there were not so much Top Domain Name Extensions. What I knew were .com, .net,.edu, ect. And I was quit happy with all of those! (ignorance=happiness?)
Until recently I found more and more companies are adopting strange domain extensions like: http://del.icoi.us, http://bu.mp...
and I was totally puzzled. What does it mean? Obviously what I care is SEO significance, but I am also interested in other related aspects, like what is it differences between well-known extensions? for ordinary users? It seems clear that those new extensions are quit easy to write and memorize, does it mean I should buy domain names like bu.mp or http://i.i?
Thanks for your time?
.us and .mp are country extensions. See here a list of those extension.
If you should register domains like bu.mp is up to you.
I found out that here in The Netherlands people (ordinary users) find .nl and .nu confusing. I always advise to register the .nl as well if clients want to use .nu
So the well-known extensions still have their value.
Related
So my question is simple and probably your answers will tell this is not possible...
Maybe on the first use of the dll file, I should see what is the MAC Address and put a restriction on that base? :)
Interesting question! You could manage a kind of white/black list (of course encrypted) in your DLL and handle the restriction code in DLL_PROCESS_ATTACH and then return TRUE or FALSE according to your needs.
You will need to search for specific technology or language and see what standard approaches do people use for this.
There is a trade off between how difficult it is to set up your product and the defence level. The tougher you make it for the bad guys, the tougher it will become to use your product.
You can use some sort of obfuscation and library encryption, which will work providing your user has a key (or password).
I plan to provide content/services across multiple (similar and related) subcategories. In general, users will only be interested in the one subcategory related to their needs.
Users will be searching for the term that would be part of the domain, subdomain or URL.
There's three possible strategies:
primary-domain.tld, with subdomains:
keyword-one.primary-domain.tld
keyword-two.primary-domain.tld
primary-domain.tld, with directories:
primary-domain.tld/keyword-one
primary-domain.tld/keyword-two
or each keyword gets its own domain:
keyword-one-foo.tld
keyword-two-foo.tld
From an SEO point of view, which is the best approach to take? I gather that having one overall domain would mean any links to any of the subdomains or directories weight for the whole site, helping the ranking of each subdomain/directory. However, supposedly if the domain, keywords and title all match nicely with the content, that would rank highly as well. So I'm unsure as to the best approach to take.
The only answer I think anyone could give you here, is that you can't know. Modern search engine algorithms are pretty sophisticated, and to know which marginally different naming methodology is better is impossible to know without inside knowledge.
Also even if you did know, it could change in the future. Or perhaps it doesn't even come to the eqation at all, as it is open for abuse.
99% of the time it comes down to content. Originality, quality etc etc.
As long as you provide the best Quality Content and Make your website more SEO friendly, later domain names doesnot matter,
I personally prefer create several domains and maintain that, when the content grows, you can map it, this may help when you think of content Delivery networks.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Human factors design (meeting psychological needs in UI design)
What should a developer know about user interface design, usability and less technical aspects of human computer interaction?
What knowledge of usage scenarios, user behavior patterns and the psychology of user to computer interaction should we embrace to design effective software that helps users solve their problems in a natural and uncomplicated way without building barriers and creating obstacles?
There is much more to design of software than building the architecture, implementing the requirements and creating a nice-looking interface. A beautiful interface may not necessarily be useful and effective, and vice versa, an ugly software utility can become a favorite tool for many users. What at least basic knowledge should a decent developer or designer have to smooth the user experience?
Please focus on one issue per answer, describe a problem, bring examples, how the user experience is impaired and what are the ways to address the situation.
I will start:
PROBLEM: Interfaces with lots of controls and options immediately on one screen can be overwhelming to users. They will have to waste time looking through all of them trying to locate the one option they need. They'll also get distracted in the process, see one more feature, go there to learn about it and maybe read help to see if it can solve their problems, then another one and so on until they are completely lost.
EXAMPLE: As a good example I will cite the Microsoft Word (as well as other Office applications) of pre-2007 version. The sheer amount of menus and options has always scared me. I managed to remember where were the options I needed most often but that's it. Everything extra, I tend to google for things I need to learn where this particular feature is located in the forest of options.
SOLUTION: Hide out all extra options behind a few menus and submenus logically structured for the user to be able to locate them through the process of logical thinking. The 2007 redesign has obviously taken the problem into account by grouping the options into tabs. I found many new options I needed without googling but just by thinking where it could belong and looking there. Not that it has always worked, but the improvement can be felt.
Now, what are your ideas?
Useful and effective interfaces are beautiful. Look at them as a UI designer, not as an art major. :-)
Simplicity; as few choices as can accomplish the needs.
Convention; follow patterns the users are already familiar with.
Observation; watch the users, and smooth the places they have problems.
Gentleness; write human-readable errors. Don't upset the users.
Consistency; do things the same way everywhere in the application. Have one person write all of your text, or write a standard that text must meet.
Learn to listen.
Users will tell what they want but not in the words that you're used to. Socialize, sit down, take your time and listen. Watch them work, ask questions. Bring up some ideas "How would you like...?" and listen to the replies. Don't assume that something would be better for them, ask them. Don't force them down a certain path because it's more simple to code.
Interfaces with lots of controls and
options immediately on one screen can
be overwhelming to users.
GMail has this slogan "Search, don't sort". The same principle can be applied to user interfaces. As you mentioned, users are already doing this themselves by googling for features.
Now the next step is to build support for feature search right into the application. Hit a keyboard shortcut, type a few keywords, and click on the feature you want to use. The IDE Insight feature in the upcoming RAD Studio 2010 does exactly that.
Problem: user interfaces often don't have a 1-to-1 correspondence to the domain model:
There are communication problems
because programmers talk about the
hidden domain model while users talk
about the GUI.
There are maintenance problems
because users are constrained by the
task-based user interface. They regularly need
to ask for "a new screen to do this" even
if the domain model may already
support it.
Solution: the naked objects architectural design pattern. To take this to the extreme you might even generate the GUI automatically from the domain model.
I know the question is a bit old, but I'm surprised to see that no one mentioned Joel Spolsky's excellent article : User Interface Design For Programmers. It's definitely something every developer should read. There are no especially brilliant or original ideas in it, it's mostly common sense, but it did open my eyes on some not so obvious points...
I suggest reading "The Design of Everyday Things" by Donald Norman.
I use to think asthetics were useless until I tried to sell my house. Sturdy foundation, 3 brms, 2 baths, 2 car garage, fenced yard, blah, blah blah - until I got rid of the stink from my 3 dogs nobody would touch it.
The more visually pleasing the app/site is, the more chance it will get used. Now a user will give it a try and determine if it does anything they want. Finally, how usable is it? This is a point when you will probably get more feedback.
Just like the house: get rid of the clutter, clean everything, start with a general color pallette and let the user add the crazy colors if the want them.
If you really want your eyes opened, take a course in Human Factors Engineering.
I have worked at a pharmaceutical company for the past two years and I think that the design of the interface is nearly as important as the functionality. Watching users struggle with old complicated legacy code is the primary reason for re-designing it. Functionality is seldom the primary reason for redeveloping code or replacing it.
Usability studies
Watching people use your code
Extreme programming (Delivering preview code intermittently throughout design process)
Are all essential to delivering code that not only meets the users needs but makes them happy and productive. At the end of the day, programs will only be used if they make you happy and productive.
I have a Mailman managed list with years of history that I want to migrate into a web-based forum. Things it would be nice to do:
Keep the mailing list going for those who are used to and prefer it to a web interface, but have it integrate with the web-forum activity.
Take the web-based forum posts, and send them out to the mailing list.
I have run sites based on phpBB, Drupal, Simple Machines, etc., and am able to do a little bit of coding if that was what was required to integrate some package into Mailman, or replace it entirely. But I'm unaware of what is available, commercial, or open-source, that could accomplish this. I am also open to replacing Mailman, if the candidate package can perform its functions reasonably well and integrate well into its own forum.
Even if the phpBB/mail2forum option is using the older version, it is a nice option. OpenSceneGraph just implemented this for their long running mailing list, and it seems to work flawlessly. It's the only option I've seen that allows for forum posts and mailing list messages to work very seamlessly, and has the means to allow for tags to separate forum subjects from mailing list posts, etc.
Their v2 dev works with phpBB3, too - so if you're willing to live on the bleeding edge, that might be an option.
So far, here's what I've looked into:
Drupal, with its Mailmanager and Listmanager modules, though I've been having trouble turning on the IMAP feature so it can talk to my mail box (clients can access it fine), and the Drupal's forum module isn't really up to the feature level I'd like.
PhpBB, mail2forum, though it looks like currently it only works with the older phpBB version, so not really an alternative for me.
The only one that seems to really "work" is FUDforum and its maillist.php module, which integrates directly at the procmail level, nice. I can take all my Mailman archives and "formmail -ds" them directly into a chosen forum.
I've started a bounty for this issue, I'm looking for something, even commercial, that really integrates the email interface into the forum experience for the end users, particularly the handling of accounts. With FUDforum I'm still going to have to resolve the separation of the Mailman accounts from the FUDforum accounts.
I ran across this on the web: http://mail2forum.com/
I haven't used it but it looks promising and has both a 1.2 stable version and a 2.0 development version, so it's not a derelict SourceForge project with 1 developer and no commits, or anything :)
Theoretically my org may use it at some point in the next year or two, but we have to finish our own Listserv to Mailman transition first.
Well, based on what you've said (first, that you're able to do a bit of coding and second that FUDForum would work for you except for the issue of maintaining list membership, have you considered that:
Mailman stores its user information in a plain text file and
FUDForums stores its user information in a single sql table
The obvious solution would be to declare one of these master (probably FUDForum, since it looks as if it holds a proper superset of the Mailman info) and have a little script/cron job that copied changes from the master to the slave.
A passing note -- neither of these systems appears very secure (actually, they both look leaky as all get out) and combining them may well reduce the collective security even further. If you are doing anything even remotely confidential you should rethink your goals, and in any case you should take appropriate steps to protect your system from attack.
I know an SME which switched from the mailing list to phpBB!
If you want to keep your mailing list, you have also to maintrain it.
Finally the people I know diabled the mailing list service.
It seems to me that if you are writing in an interpreted language that it must be difficult to sell software, because anyone who buys it can edit it/change it/resell it without much difficulty.
How do you get around this? I have a couple of PHP apps that I'm reluctant to sell to people as it seems that it's too simple for them to change/read/edit/sell what I've produced.
Hardly anyone sells code. We sell the ability to create, edit, support and understand the code.
As a potential buyer of your application, I might find these features attractive:
The ability to change the code to suit my needs
The ability to read the code to better understand what it's doing
... and yes ...
The ability to sell my modifications
All three of those are features.
The third one might be a feature you can't afford to give me. Fix that through legal measures, not technical measures. That's what licensing is for. You could also sell more expensive licenses which do allow resale.
There are things you could do to remove the first two features, but bear in mind that in doing so you are reducing the overall value of your product to some people, and therefore its sale price.
For many people the primary reason for using Open Source software is not that it costs nothing -- it's that you get the source code.
People sell the service of creating web sites all the time. Also, even a compiled language can be altered, it`s just more difficult.
Most of the time the user base does not understand how to make the changes or what to do with the scripts so you are really selling your knowledge of how to install and change the scripts.
Don't sell the software, sell "licences".
I'll try to explain better, build the web app but provide hosting for it. this way your client will never get to "hold" the source code.
If you really must deliver the source code, Obfuscating is the way to go ;)
Possible routes to go:
Translate to a bytecode, binary or an obfuscated format
For instance, Splunk is written mostly in Python, and distribute bytecode. The EVE online client uses Stackless Python to compile to an executable binary.
Host the solution yourself
Put up a website, charge for use.
License the software
They get the source, but cannot legally modify or redistribute the source.
Open source the solution
Anyone can change the code, but you are the de-facto authority on it, and you can earn money by selling support, consultancy and customization services.
You could also consider a combination of approaches. E.g., partition your solution into several stand alone packages, and then open source some of them, and sell bytecode versions of other parts. What you then sell is the complete solution, as well as other services, and some people may benefit and enhance other parts of the solution.
Plenty of companies make money off of applications in interpreted languages and happily distribute the source code with them. Don't take this personally, but your program probably isn't going to be popular enough to have a large following of pirates. And anybody who would pirate your software probably isn't going to buy it in the first place. If they can't pirate it, they'll pirate somebody elses.
Whatever you do, please don't obfuscate your code. It's not an effective means of preventing infringement and it won't do anything other than make life miserable for you and your customers.
Protecting your secret bits is getting more and more difficult.
IMHO, your solution really depends on your target market. If you are targeting business, just give them the code with a good license, and possibly some type of defect so you can determine who gave your code away if that ever happens. Businesses will mostly pay for your app just to stay compliant; it's not worth the legal hassles. And if an individual gets your app for free, that's probably a good thing, since they will try to convince their current and future employers to buy it.
If you are targeting individuals, and can do it as a web app (which you obviously are with PHP), do it as a hosted service, and either sell a monthly subscription or allow free access and find another way to monetize it.
If you definitely need to or want to distribute it to individuals for whatever reason, you can give it away for free, and try to monetize customizations, add-ins, & other support features.
This is a problem that's been discussed a lot, and a few hours’ worth of really focused googling should reveal all the current philosophies on this.
I hope this helps.
Obfuscation may be a good way to go
With PHP you have the option of using the Zend Guard for PHP. I believe it compiles the source code in a way similar to what the php interpreter does,
so it should also increase performance. Of course the price of $ 600 may be too much for your liking ;-)
Anyway, I see no reason why you shouldn't distribute your code with an open source license (see the Open Source Initiative for a list of licenses available). You can find one that prohibits your customer from redistributing your app.
EDIT:
As Novelocrat points out in his comment, a license that prohibits distribution is per definitionem not an Open Source license, the term Open Source refers to a lot more than just the availability of the source code. (See also the answers to this related question for further discussion).