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 11 years ago.
I would like to design an eCommerce website with WordPress. I don't want to do it from scratch so I'm looking for a free plugin. The features I expect it to have are:
shopping carts
shipping modules (Canada post etc..)
payment using Paypal
customizable themes
I came across : WP-eCommerce
it claims to be free, however I found out that some documents require payment. All the payments, shipping modules are not free, am I right?
Actually, I'm not very familiar with Wordpress, if possible, could someone suggest an easy to pick up, but powerful enough eCommerce plugin for Wordpress?
Thanks!
WP-eCommerce is the only plugin for WordPress worth looking at when it comes to eCommerce. You do get a lot for free.
That said, Alex makes some great points about how WordPress is NOT ideal for eCommerce.
However, after having completed 2 websites with WP-eCommerce and 2 websites with Magento Commerce, I can say that there is a HUGE difference in the time it takes to complete.
WP-eCommerce can be set up relatively quickly with very little customization to get it to look decent in your own WP Theme. A full eCommerce system such as Magento, on the other hand, has a huge learning curve and you will spend 3 times as long anytime you want to change anything.
It all depends what you're going for. If you want something simple that can be tweaked a little but doesn't need to be a great robust long-term solution, I would definitely consider WP-eCommerce. Otherwise, go for a real eCommerce platform.
Alternatively: Zen-Cart looks simpler than Magento but without some of the flexibility. Whatever you do, DON'T go anywhere near osCommerce.
Trick question: WordPress, a very simplistic blogging platform, should never be stretched into something as intricate as an e-commerce solution. An e-commerce platform offering a simple blogging module is another matter entirely.
Since you don't know much about WordPress anyway, you may want to consider using a e-commerce platform like magentocommerce.com, zen-cart.com, or oscommerce.com. All of them are PHP/MySQL based, like WordPress.
Wordpress.org has an extensive list of all of the various extensions and add-ons that are publicly available. If you look under all results with the ecommerce tag, you might find something that better suits your needs. If you are already using Wordpress as your content management system, why not just outsource the shipping and order management with something like Paypal or Google Checkout? Just have your catalog and if they like it, the can click "order with Paypal" or some such.
Also, I just went and looked up WP eCommerce and it is incredibly generous what they offer out of the box for free. The things that cost are listed at the Gold Cart premiumm upgrades page, and from what I can tell, most of the features you could do own your own, other than the added payment options (none of which I've heard of).
You should take a look at the PHPurchase wordpress ecommerce plugin. It's got great features to sell digital products, physical products, and even recurring billing/subscription products. There are membership management features built in so you can require an active subscription to see certain content on your site. And, perhaps best of all, it is backed by real, professional support. Check it out here: http://www.PHPurchase.com
wp-ecommerce definitely is not the only e-commerce plugin out there, check some of these out before you go the route of using magento or zencart (both of which are a major pain in the ass)
http://sixrevisions.com/wordpress/top-5-excellent-e-commerce-plugins-for-wordpress/
also I hear shopify is good and can be used with wordpress although I've never tried it out
Related
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.
Are there any tools for finding if a page is SEO complaint and if it's not then suggest something to make that page SEO complaint?
Also note that I want to do this research on offline pages i.e. these pages are not on web yet.
The best all purpose services are:
WooRank
WebsiteGrader
Xinu
Google has their own tools which as close as you can get to official 'compliance':
Google Webmaster Tools
Google Website Optimizer
Google Adwords Keywords Tool
SEO is an entire industry, and the rules are always changing.
(See here for a great list of some of the more pronounced changes on Google this year.
And here for some of the more noticeable differences from Bing.)
Some of the better SEO targeted sites are:
Web-strategist
webanalyticsbook
SeoBook
Viget
A monitoring service you should look at:
http://conjection.net/
One of the better articles I would recommend is:
- http://community.seobook.com/45711-post172.html
You should also make sure your page is loading optimally, it will effect the SEO even though it is its own field:
Load and performance - Pingdom and Uptrends.
If you are technically minded, install Yslow or PageSpeed and look at the score.
You can try the Search Engine Optimization Toolkit. Tried it once and it works well.
Got broken links on your site? Is your HTML SEO optimized? This fantastic free tool answers all these questions and hundreds more as it chews your angle brackets for you, creating flexible reports and a full queryable database of your site. -- Scott Hanselman
It's a bit late but I made a presentation with great tools for SEO that I used.
You will find a lot of Firefox Add-ons and Google Chrome Extensions to analyze your page and get suggestion to respect main search engines recommendations.
These slides also present other tools usefull for SEO expert like : google products, online services, wordpress plugins, ...
If it could help someone else, it's here : http://slidesha.re/KOoDad
Hope this help.
I don't know if "compliant" is the best term to use. There isn't a standard.
Rather, there is a set of best practices that have been determined through observation of search engine behavior in reaction to certain aspects of page/url structure.
That being said, I would first take a look at article on About.com titled "White Hat Vs. Black Hat SEO" You definitely want to avoid the black-tactics while abiding by the white-hat tactics.
In a nutshell, the focus on white-hat tactics is on quality content relevant to the subject. Without that, your pages are pretty much dead in the water (assuming you don't subscribe to black-hat techniques).
Offline tools, I did not know which will do this.
You could upload it for a short time or protect it with a password if you do not want that other people see the webpages.
Online-Tool: http://www.linkvendor.com/
I have found the following site useful with Keyword Destiny and more content driven queries in the past... http://www.seocentro.com/tools/seo/keyword-density.html
i use this tool quite often. it doesn't look very good but i found the data to be really useful
article underground keyword density tool
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 am going to change my working sphere from Enterprise Web Applications written for concrete business process to Public Web Sites that will be accessible to all users around.
What is difference between this two spheres at the most top level? What specific characters I need to know about modern web sites development?
I suspect one could write books about this.
I suppose the first difference is the user base. With an enterprise, you can, at least partly, ensure the users are doing what they are supposed to - and if not you know who they are and where they live. Further, they can be fired for abuse. On a public web site, you almost have to assume that some part of your user base is not there for a positive reason. So be paranoid - if they're not attacking you yet, just wait.
A second related point is that users will find ways to use (abuse?) your site you never thought of. Plan for the worst, hope for better.
Third, language, culture and usage varies across the world. A form, for example, with "zip code" that accepts just 5 digits may make sense in the US but is useless in the UK. And asking for a state and restricting it to two characters likewise makes no sense say in Italy where Italy IS the "state". This also applies to actual content - that joke you think is so very funny may be offensive in other countries. And never under estimate the ability of some folks to be offended at anything.
Fourth - get a good bunch of beta tester and test your site, and updates, carefully and thoroughly.
Fith, have a plan for scalability - if you suddenly get "discovered" can your site take the traffic.
That's 5 things at least.
In an enterprise application, functionality and efficiency trump aesthetics every time. This is because you have a captive audience. The people who use your application are being paid to use it.
However, when opening an application up to the public, aesthetics becomes more important. There are always alternatives, and a given person will be more attracted to the application which looks better. Granted, functionality is still very important for repeat users, but you won't get people in the door if your application looks amateurish.
Browser agnosticism - In enterprise apps, it used to be that the developer would target the app at a specific browser, just for simplicity's sake.
In internet accessible apps, the developer must target the vast majority of browsers. While this has gotten easier in the last few years, it is still a issue that needs attention.
Scalability - its easier to scale an enterprise app, its easier to predict the growth of usage of the app, or simply design for access by all users in the org at once. This is not generally the case for internet sites. The day you get slashdotted, or dugg is the day that you learn this. Better to design scalability in from the start, rather than have to learn it at the time that your site starts to suffer.
In addition to Zack's answer, I would say that a web site/application that is open to the public needs to be constantly evolving/refreshed in order to grow your user base and keep them. Whereas on a more closed system, consistency and reliability are key priorities.
Depending on the nature of the application, if it has significant amounts of content Internationalization and presentation of content are hugely important.
As Zack mentions, public users have a lot less tolerance for poor UI than enterprise customers do. That said, public users are more tolerant of incremental change; you can upgrade a live site as you feel like it (as long as it works, of course!!) without having to go through endless feature-request prioritization committees and user-training requirements.
Public web sites needs to be easy to use. While it's important that they look somewhat polished, don't ever let polish get in the way of ease of use. For example many designers like fixed width layouts because they are more predictable, many users like fluid width layouts because they use the space more efficiently. Side with your users.
Enterprise users can be forced to deal with needlessly-complex systems (lord knows I am more than I'd like), the general public cannot.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to land my first programming-related job, and I found a website for a company which is accepting resumes for an eCommerce development position.
This is the requirements they listed:
To be proficient in:
HTML (hand-coded)
CSS
PHP
Javascript
MySQL
Preferred skills:
PEARL
Linux
The fact that they (unless they're actually using the PEARL programming language) misspelled perl and have a fairly bland portfolio aside, I can do all of this--I mean, I need to touch up on my Javascript and learn a bit more MySQL--but I can do all this, and I'm sure I can pick up perl in no time. But I was wondering--what exactly does an eCommerce developer do? Is this like, building shopping carts? User login systems? Or does it just mean doing everything except design on corporate websites?
eCommerce has one big word that goes with it Security.
Do you feel confident writing secure code? Bearing in mind that your code will be handling the users credit card information.
Now, there is alot that goes into building an eCommerce solution from the ground up
Product Listings
Adding/Removing Items
Sort by size/shape/price/color/...
Search
Filtering results
Shopping cart (harder then it sounds)
Database or Session?
Adding/Removing Items
Checkout
Integration with payment API
Reporting
Inventory
Security
XSS
SQL Injections
I would suggest that ecommerce is so much more than a specific technology. ECom is more about how the database is built and the features that are required. There is a good book that I read 10 years (a long time) ago that goes into ecommerce with asp classic. But there are many new ones using newer technologies here.
The big key is how you structure your data, products, options, orders, order details, credit card/user data, etc. Also, the various ways of processing transactions. How to handle order pipelines. When to offer navigations away from the current page and when not too. How to make product recommendations. Dealing with tax API's and shipping API's. You might consider downloading DashCommerce (a .net application) or something similar that fits your preferred technologies to see how they have set things up. Install something. Get it set up to feel the pains for data management. ...also to feel the pains of navigating a shopping cart (adding products to the cart, updating the cart, checking out, setting up an account or having an anonymous checkouts).
Being an commerce developer generally means knowing how to work with Verisign (now paypal) or similar payment processing. How to intercept fraudulent transactions and deal with them appropriately. How to work in a high transaction environment (caching, tierd architectures, queues, web services). Cross linking products based on user history/profiling to maximize transactions (think candy at the check out stand of a grocery store). Knowing how to work in a secure manner with sensitive data which generally means encryption techniques, setting up DMZ's, working with proxies, etc. Take a look at using some form of a rule engine for order pipelines so that your business rules are separate from your application logic. Understand coupons schemes, discounts, etc. Frequently ad campaigns are heavily used for generating side income.
Ecommerce can be a big topic!
It all depends on what you are working with.
I have been working as an e-commerce developer for half a year now.
I have used the Magento platform for all of my work.
Since standard Magento is already very secure you won't have to do much security code.
Mostly you change the layout and the design of the standard Magento shop and add any new features the client wants.
Most of these can be achieved by downloading custom modules built by other developers or you can build them yourself. Building a Magento module the right way is quite difficult for someone who is kind of new to programming or new to Magento.
I know this topic is rather old, but i thought someone might still benefit from this answer.
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 9 years ago.
I need a tool for collecting feedback and new ideas inside our company regarding our internal IS product. The problem is the acceptance level for such a tool.
Most of our colleagues are not IT oriented, so a solution like BugZilla or Jira is way to complicated for them to use. You need to create an account, take care of a lot of parameters before submission, new ideas about new software doesn't really fit well in these tools, etc...
So, here are my requirements:
No login need, or optional.
Few fields to enter.
If possible a WYSIWYG editor for the main description field.
Web based or E-mail based (we use outlook internaly).
Free (as a beer).
Not too chaotic (a Wiki is not an option)
I've take a look at uservoice (of course), it's really a nice tool for experienced people, but too complex for my target users.
Is the feedback you are seeking possible to collect through a questionnaire? There are many free solutions that provide you with questionnaire forms very easy to use, and if none apply it is also something relatively easy to implement.
I also do not understand why a wiki will not be a good solution, but regarding the Outlook, you have the possibility of doing simple votes (approve/reject) (yes/no):
See: http://www.microsoft.com/atwork/worktogether/forms.mspx
If the barrier to actually use the tool should be minimal, then perhaps the best way to collect the feedback is to use an e-mail address. Everybody knows how to use the system, so there is practically no barrier. And the feedback that is provided has to be processed by developers / management anyway, in order to decide what concrete actions are going to be taken. The developers can then use whatever system suits them best in order to keep track of bugs, immediately required functionality, nice-to-have features that can be implemented later, etc.
Some "defect tracking tools" handle this.
Don't vote down because of "defect tracking". Some of the tools are enterprise and handle incidents, requents, requirements, etc. And, you can go to one place for bugs and enhancement requests.
Microsoft's Exchange server has support for Public Folders, email lists/groups. This may be an easy introduction to collaboration for your environment, using tools that are familiar. From the Microsoft Help on Public Folders:
Public folders are an easy and
effective way to collect, organize,
and share information with other
people in your workgroup or
organization. You can use public
folders to share files or post
information on an electronic bulletin
board.
I'm not sure how effective the tools for managing those "lists" are - I'm not sure if you can mark responses such that all users see the mark, for example.
But it is probably a good start. As people start to see the value of collaboration, something along the lines of a Wiki becomes more appealing.
I've got to say that Confluence, especially now that editing with Open Office or Microsoft Office tools is possible really deserves a look. Not free (as in beer).
I would think a locally hosted php-bb (or other...) forum would be a good choice, as you could moderate it and have a FAQ and history that people could check before duplicating suggestions. So, that's the advantage over a simple email address, and it has a simple, known interface.
What's too complex about Uservoice? The main UI is a single question ("I suggest you ..."). Your users can be anonymous, one field to enter, web based, free for small users. Seems to tick all the boxes except the visual editor. Even administering it is not terribly tricky. (I use it for my iPhone app.)
It looks like you're facing a very standard tradeoff - you want your feedback to be structured, but you don't want any impositions upon your users.
You can't have your cake and eat it too. Why is a wiki off the table? Wikis were designed to balance this kind of tradeoff.
You could use Google Documents to create a shared spreadsheet. Your uses will need Google accounts, but they only need to log in once and a cookie will remember them for next time.
Hum, I've found that we've also InfoPath as part of our toolset. I've never use it, but maybe that it could do the job.
How about using for example Google groups? I've found a mailing list works quite well for this kind of purpose.
Edit: or how about http://getsatisfaction.com/
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 11 years ago.
An obvious answer is "an internal wiki". What are the pros and cons of a wiki used for software documentation? Any other suggestions? What are you using for your software documentation?
Loren Segal - Unfortunately we don't have support for any doc tool to compile information from the source code comments but I agree it would be the best way to store technical documentation. My question was about every kind of documentation tho - from sysadmin type to user documentation.
That's a very open ended question, and depends on many factors.
Generally speaking, if you use a language that has good documentation generation tools (javadoc, doxygen, MS's C# stuff), you should write your documentation above your methods and have your tools generate the pages. The advantage is that you keep the source of your text alongside your code which means it is orgnanized in the logically correct place and easily editable when you make a change to the behaviour of the method.
If you don't have good doc tool support or don't have access to source code, wiki's aren't a bad idea, but they're a second choice to the above.
Note: I'm talking only about code documentation here. Other artifacts obviously cannot be stored alongside code-- a wiki is a great place to put those documents. Alternatively if you use some CMS you can simply commit them in some docs/ folder as text/pdf/whatever files to be editable via the repository. The advantage there is that they stay with the repository if it is moved whereas a wiki does not (necessarily).
Tools are important, but don't get too bogged down in finding the magic tool. No tool I've found yet has a "document everything magically using tiny invisible elves" tickbox. :-)
A wiki will work fine. Or Sharepoint. Or Google docs. Or you could use a SVN repository. Hell you could do it with pens, notepaper, and a file cabinets if you really really had to. (I really don't recommend that!)
The big important key is you need to have buy-in throughout the organization. What happens in a lot of shops is they go and spend a bunch of time and money on some fancy solution like Sharepoint, and then everyone uses it religiously for about two weeks, and then people get busy with hitting the latest milestone and that's the last anyone hears about it.
Depending on your organization, field, the type of products your developing, etc., there are a few solutions to that, but one way or another you need to set up a system and use it. Appoint someone the official documentation czar, give them a cluebat, and tell them to hit people in the head everytime they say "oh yeah, I'll finish documenting that next week...". if that's what it takes. :-)
As for tools... I'd recommend Confluence by Atlassian. It's a fine wiki, it's designed to work in an enterprise environment, it has a lot of nifty features, it's customizable, it integrates well with some of the Atlassian's other nifty tools, and is basically a pretty solid product.
«Software documentation» is a very general term. There is «End User documentation», «Developer documentation», «QA Documentation». First one is usually developed by qualified techwriters. Other ones may be dynamically formed from wikis, documentation comments from source code etc. All this stuff maintenance process usually is very complex and each software company follow its own way. But there is one necessary point for all these ways: each code commiter, architect, manager, qa engineer MUST store well arranged each piece of information which may be helpful for the others. And someone else MUST keep an eye on this pieces storage and rearrange pieces if required. All this steps greatly improve all activities related to development process.
Assuming you are talking about code documentation versus user documentation, an internal wiki is great if you do not need to distribute the documentation for the code outside of your organization, to contractors or partners.
Javadoc or DOxygen is more suitable if you want distributable code documentation.
If you are referring to user documentation, you may want to have a look at DITA.
I started experimenting with a way to do user documentation with these goals:
Markdown/Html/Javascript/file-based relatively linked documents for portability (can run on local file system or you can throw it on a webserver), built-in handling of screenshots (interactively resize), and open source in case anyone else may want to do something with the crazy thing.
Your document source is written in Markdown and rendered to Html via Javascript at browser runtime.
Mandown - http://wittman.org/mandown/
We currently use inline documentation parsed by an external application (PHP + PhpDocumenter) plus various internal wikis. At times it's painful at best (mainly because only one person update the wikis or the docs...)
However, I've been looking at using ikiwiki to do internal docs. It integrate with your source countrol system (including Git, Subversion, Mercurial, Bazaar, TLA and Monotone) so all your docs track with your project. It is built in Perl and has an extensive plugin system (including multiple markup languages, with the default being Markdown). Also, the source control system is plugin based, so if what you use isn't immediately supported you could add your own. In your preferred language, if need be, since it supports non-perl plugins, too.
My company uses a variety of Sharepoint and a wiki. Sharepoint for specific documents like requirements, presentations, contracts, etc, while the wiki is used as a help guide a developer repository for tutorials on using internally developed libraries.
Yeah, we use a wiki, we also use Google documents. I find that Google documents is better than most wikis I've tried and, if you don't need to track all changes, you lose nothing. Google docs provides a good collaboration framework.