Just released an extension to reduce duplicate content issues by
giving each product a single URL.
Here's what it does:
- 301 redirects from taxon-aware product URLs, for example:
- Handles Taxons like Amazon: no breadcrumbs at the top of the product
page; they are replaced with a "Look for similar items" section lower
down the page showing all taxons this product belongs to.
- The taxon-aware product URLs are no longer used in the product
listings pages
Just wondering: wouldn't it be more useful (SEO-wise) to retain some info about categorization in a product's URL?
We could nominate one taxon for a product as the "primary" one (criteria to be decided) and generate the product's link from that, eg if p.taxons = [t1,t2,t3] we take t1 as the primary one and so generate seo_url(t1,p)?
I am facing a similar choice in my revisions of the sitemap extension, for the case when unique urls are required.
@sean: is the partial "products/products" redundant? can't find anywhere that calls it - all calls now use "shared/products"
Maybe there are some benefits to putting the categorization in the
product's URL - I wouldn't want to make that call for anyone else.
My own personal opinion on the subject is:
- If you change the taxonomy tree for a product, then the canonical
URL for that product changes. Not a problem if you use the taxon-less
'/product/ruby-on-rails-mug' type URLs.
- If there are benefits for putting the category in the product's URL,
I think they'd be small, plus, I'd be optimizing the product page for
the product name, not the category it belongs to. (When optimizing
the category page, then yes, I think for the URL to contain the
category name is a good idea).
- Main thing about the URL is to get the product name in there. I
wouldn't want to dilute that with the category name.
- When I have a problem like this I wonder how the big boys do it. I
don't think Amazon put the category information in the URL. They
avoid the whole breadcrumb-tracking problem by doing this. Check out
a product page on Amazon - no breadcrumbs and I think it is an easy to
use site. They rely on users knowing how to use a back button or
opening new tabs or using the "Your search history" section in the
footer.
- Simplest solution often works out best
On Jul 18, 6:43 am, Paul Callaghan <paulcc....@googlemail.com> wrote:
> Just wondering: wouldn't it be more useful (SEO-wise) to retain some
> info about categorization in a product's URL?
> We could nominate one taxon for a product as the "primary" one
> (criteria to be decided) and generate the product's link from that, eg
> if p.taxons = [t1,t2,t3] we take t1 as the primary one and so generate
> seo_url(t1,p)?
> I am facing a similar choice in my revisions of the sitemap extension,
> for the case when unique urls are required.
> @sean: is the partial "products/products" redundant? can't find
> anywhere that calls it - all calls now use "shared/products"
This is an excellent extension! Steph has been after us for a while now about the SEO impact of multiple URL's for the same product. I'm actually strongly considering for the core. I've filed a ticket[1] in Lighthouse on this.
I'm planning on keeping this ticket open for a week so if you'd like to weigh in on this going into core then please comment on the ticket thread.
Eliot Sykes wrote: > Maybe there are some benefits to putting the categorization in the > product's URL - I wouldn't want to make that call for anyone else.
> My own personal opinion on the subject is:
> - If you change the taxonomy tree for a product, then the canonical > URL for that product changes. Not a problem if you use the taxon-less > '/product/ruby-on-rails-mug' type URLs.
> - If there are benefits for putting the category in the product's URL, > I think they'd be small, plus, I'd be optimizing the product page for > the product name, not the category it belongs to. (When optimizing > the category page, then yes, I think for the URL to contain the > category name is a good idea).
> - Main thing about the URL is to get the product name in there. I > wouldn't want to dilute that with the category name.
> - When I have a problem like this I wonder how the big boys do it. I > don't think Amazon put the category information in the URL. They > avoid the whole breadcrumb-tracking problem by doing this. Check out > a product page on Amazon - no breadcrumbs and I think it is an easy to > use site. They rely on users knowing how to use a back button or > opening new tabs or using the "Your search history" section in the > footer.
SEO best practice recommends to include the category in the page title with a template like *Product Name | Category Name | Store Name*. It's only acceptable to include the category in the url if products can only belong in one taxonomy, which is not true for Spree.
I've read some SEO best practice articles that recommend that there only should be *one* taxonomy and products can only be assigned to one group, that this taxonomy should be the most meaningful/natural grouping to a user, but then content and product groups can be created for separate targeted keywords (landing pages). For example, a single natural taxonomy to separate gear might would contain bikes / climb / ski / clothing as the categories where the products do not overlap. A targeted keyword landing page might be The North Face (a prevalent brand) clothing or Black Diamond (another brand :)) climb.
Breadcrumbs are an important & common usability feature that should not be *thrown out*, IMO. The only justification I could see to throw out breadcrumbs is if you have a one-level taxonomy and the links to all these categories is contained on every product page. To track breadcrumbs and follow best practice SEO, the "big boys" may do one of the following: - store navigation information in the session - store navigation information in the cookies via onclick JS - append a '#' (relative url) to the url with navigation information following the '#' (search engines do not index after the '#') - force one taxonomy group per product - use session history to generate a breadcrumb
Having implemented all of the solutions mentioned above, I wouldn't say any of them are particularly difficult. Sure the simplest solution would be to not include breadcrumbs at all, but that's probably not something I'll ever want to say to a prospective client: you: "Spree doesn't offer breadcrumb tracking in the core. That will take me approximately 5-10 hours additional to build out." client: "That's an essential ecommerce feature. Why doesn't Spree have breadcrumbs?" you: "Because Spree moved to SEO friendly urls and opted for the simplest solution." client: "Well, customer usability is a priority over SEO. Do other ecommerce packages have breadcrumb functionality?" you: "Yes."
I have recently been forced to deal with zen-cart and I've come to the conclusion that zen-cart's major failing is complexity. In trying to be all things to all people it has become incredibly complex and a major PITA to modify and understand.
The lesson I think is to not try to be all things to all people in the spree core. We need to remember the original goal for Spree and keep only truly core ecommerce functionality in spree and have the rest be in the extensions.
SEO is about Marketing and the base needs for SEO will change as search engines change, and as fads come and go. Spree should support the lowest common denominator and push the complex SEO support cases out to extensions.
> The lesson I think is to not try to be all things to all people in the > spree core. We need to remember the original goal for Spree and keep > only truly core ecommerce functionality in spree and have the rest be > in the extensions.
I agree. The question is, which behavior (current or proposed) are you arguing for? That's not clear to me.
That said, (which I agree with the premise), I would like to see more
of us (who are building custom sites for customers) to take what we
have put together with all the extensions, minus the custom business
logic and design, and make repos out of them. At least that is what I
am planning to do, because it is hard to put a system like this
together when some extensions are out of sync with the trunk, or are
missing pieces. Some of the extensions that I need are so woefully
underdeveloped because they are not as attended to as often as core.
I understand why it is the way it is, but it makes it worse sometimes
that just configuring a system out of the box.
Tim
On Jul 20, 2009, at 4:28 PM, Christopher Maujean wrote:
> I have recently been forced to deal with zen-cart and I've come to the
> conclusion that zen-cart's major failing is complexity. In trying to
> be all things to all people it has become incredibly complex and a
> major PITA to modify and understand.
> The lesson I think is to not try to be all things to all people in the
> spree core. We need to remember the original goal for Spree and keep
> only truly core ecommerce functionality in spree and have the rest be
> in the extensions.
> SEO is about Marketing and the base needs for SEO will change as
> search engines change, and as fads come and go. Spree should support
> the lowest common denominator and push the complex SEO support cases
> out to extensions.
I would like to see a spree-core, and a spree-more division where some
very routinely-needed extensions get a little more love everytime
changes happen to core. Things like (my personal shortlist)
1. ActiveShipping Integration baked in
2. A lightweight (or better) CMS
3. Coupons/Discounts (obviously under development)
4. One fork for Authorize.net, and another for Paypal Website Payments
Pro plus Express Checkout (since those 2 usually go together). Paypal
express would also not be a bad thing to just integrate as an option
across the board I think.
Tim
On Jul 20, 2009, at 4:43 PM, Sean Schofield wrote:
>> The lesson I think is to not try to be all things to all people in
>> the
>> spree core. We need to remember the original goal for Spree and keep
>> only truly core ecommerce functionality in spree and have the rest be
>> in the extensions.
> I agree. The question is, which behavior (current or proposed) are
> you arguing for?
> That's not clear to me.
> - Main thing about the URL is to get the product name in there. I
> wouldn't want to dilute that with the category name.
I would want both the category name and product name in the url, thus
giving more keywords.
> - When I have a problem like this I wonder how the big boys do it. I
> don't think Amazon put the category information in the URL. They
> avoid the whole breadcrumb-tracking problem by doing this. Check out
> a product page on Amazon - no breadcrumbs and I think it is an easy to
> use site. They rely on users knowing how to use a back button or
> opening new tabs or using the "Your search history" section in the
> footer.
I think its good to keep an eye on Amazon, but there is a lot of other
eCommerce big boys to watch too!
Every book I have read on SEO advocates the use
of breadcrumbs (the robots love them apparently, showing you have a
good site structure which
is easy for humans to navigate)
I'm in full support of having a simple + elegant solution for product urls. I think that there are many opportunities to find a simple and elegant solution that meet the criteria of best practice usability, SEO, performance, etc.
By my definition of core ecommerce functionality and the goal of Spree, SEO is important - how do you expect to explain to potential clients that Spree meets your definition of core ecommerce functionality but doesn't meet theirs which includes usability and SEO? Would you feel comfortable telling a client that even though Spree doesn't offer best practice SEO, it's search engine performance will be ok? From my experience, I find that it's best to design a system with known SEO best practice implemented -- otherwise, you cause a lot of problems that require time & money to fix and could damage your search engine traffic performance.
SEO is not just marketing, it includes technical aspects such as minimizing duplicate content, page performance, and building a system that allows the client to create and organize content that compels a user to link to and buy from the site. Sure, search engines change. This year alone, the rel="canonical" tag has been introduced and the nofollow practices were changed by google. But less trendy SEO best practices have stuck around for quite a while.
At the very least, Spree should not appear as SEO-ignorant & it doesn't have to be SEO-*trendy*. Spree is acceptable the way it is, but my frustration is that we shouldn't force canonical urls on products and remove breadcrumbs. This is an example of sacrificing usability for SEO.
I also support the notion to keep *extension* functionality out of the core, but I just don't understand why SEO best practices would be categorized as extension functionality.
Christopher Maujean wrote:
> I have recently been forced to deal with zen-cart and I've come to the
> conclusion that zen-cart's major failing is complexity. In trying to
> be all things to all people it has become incredibly complex and a
> major PITA to modify and understand.
> The lesson I think is to not try to be all things to all people in the
> spree core. We need to remember the original goal for Spree and keep
> only truly core ecommerce functionality in spree and have the rest be
> in the extensions.
> SEO is about Marketing and the base needs for SEO will change as
> search engines change, and as fads come and go. Spree should support
> the lowest common denominator and push the complex SEO support cases
> out to extensions.
The "spree-more" idea is a good one. Sean's also talking about putting together a more impressive demo for Spree which will use some of the top extensions. This "spree-more" could effectively be the set of extensions being used for this new demo, and so provide extra motivation for us to keep the exts up to date!
SEO support should be included in the core, the technical aspects are important; SEO as a whole is important. My experience is that the majority of time proven SEO best practices are also about usability and therefore important anyway, so I don't consider them as being about SEO, but about best practices in general.
Given the fluid and very specific needs of any given customer, one cannot predict (beyond those core, time proven aspects) just what this or that particular customer is going to want. If I have to tell my customer that it'll take 5-10 hours to remove breadcrumbs from the url, it's the same as if I have to tell them it'll take that time to add breadcrumbs.
I would rather see a system that allows me to quickly add or remove breadcrumbs (or any other SEO functionality) as my client's needs require. I see our extensions system as being the key to this. In order to keep the core simple, I feel we should take the standard base set of SEO best practices as core functionality, and make sure it is extremely simple to override those parts, as our needs force us. I am by no means an SEO expert, and thus won't voice my opinion on whether breadcrumbs are better than direct product links. My concern is for the architecture, and keeping spree a good base with which to start my e-commerce solutions.
>> - Main thing about the URL is to get the product name in there. I >> wouldn't want to dilute that with the category name.
> I would want both the category name and product name in the url, thus > giving more keywords.
I think this illustrates the problem that what some people find reasonable, others will not. Based on some of the feedback we're getting here I might be inclined to say that we make the category based URL and the breadcrumbs optional, if we include them in the core at all.
> Every book I have read on SEO advocates the use > of breadcrumbs (the robots love them apparently, showing you have a > good site structure which > is easy for humans to navigate)
Keep in mind the original proposal was similar to breadcrumbs. I actually think of it as showing multiple bread crumb paths instead of limiting you to the path you chose. Lets see what other think.
> I'm in full support of having a simple + elegant solution for product > urls. I think that there are many opportunities to find a simple and > elegant solution that meet the criteria of best practice usability, SEO, > performance, etc.
We may be able to come up with something. Lets give everyone a chance to weigh in and see if we can't also find some common ground. If I understand your position correctly, you are in favor of unique URL without category information but also keeping breadcrumbs using cookies or some other mechanism other then URL to generate it. That right?
> By my definition of core ecommerce functionality and the goal of Spree, > SEO is important - how do you expect to explain to potential clients > that Spree meets your definition of core ecommerce functionality but > doesn't meet theirs which includes usability and SEO? Would you feel > comfortable telling a client that even though Spree doesn't offer best > practice SEO, it's search engine performance will be ok? From my > experience, I find that it's best to design a system with known SEO best > practice implemented -- otherwise, you cause a lot of problems that > require time & money to fix and could damage your search engine traffic > performance.
Some potential clients/users will make a knee-jerk reaction based on what is or is not included in Spree and there's not much we can do about that. The best feature of Spree (according to the feedback I get) is that its lightweight. Developers are tired of dealing with a bunch of crap that they don't need.
Now, I'm not saying SEO is crap of course. On the contrary, I think we should make Spree as SEO friendly as possible wherever it makes sense.
> SEO is not just marketing, it includes technical aspects such as > minimizing duplicate content, page performance, and building a system > that allows the client to create and organize content that compels a > user to link to and buy from the site. Sure, search engines change. This > year alone, the rel="canonical" tag has been introduced and the nofollow > practices were changed by google. But less trendy SEO best practices > have stuck around for quite a while.
> At the very least, Spree should not appear as SEO-ignorant & it doesn't > have to be SEO-*trendy*. Spree is acceptable the way it is, but my > frustration is that we shouldn't force canonical urls on products and > remove breadcrumbs. This is an example of sacrificing usability for SEO.
We have to be careful about what we include and don't include in Spree (which is why I'm encouraging discussion on this instead of just doing it.) Including something that a developer doesn't want is just as potentially damaging as not including something they do. In both cases, effort must be expended to get things the right way.
> I also support the notion to keep *extension* functionality out of the > core, but I just don't understand why SEO best practices would be > categorized as extension functionality.
I agree that SEO should not be automatically considered extension. We already have the permalink URL and category URL (which some people like for SEO) in the core. I think most of us are in agreement that the categories in the URL may cause more harm (reduced spider efficiency) then good (extra keywords in URL.)
We could probably make the category-based URL a preference setting and warn users (both in the Admin and SEO guide) about enabling this when they have anything beyond a single category hierarchy.
The breadcrumbs is trickier. I'm all for breadcrumbs in general (I'm the one who added them to the code) but if we can't use the URL to generate them (and I accept the reasons for why this is the case), then I'm not so sure I want them. I'd hate to rely on some non REST way of implementing this like cookie/session data. That said, I'm willing to listen to the alternatives.
I'm pretty sure we can build an e-commerce platform with unparalleled SEO consideration compared to those before it. Will it be perfect from an SEO perspective with every best practice? No. But I don't think that will diminish what it does have to offer.
> I would rather see a system that allows me to quickly add or remove > breadcrumbs (or any other SEO functionality) as my client's needs > require. I see our extensions system as being the key to this. In > order to keep the core simple, I feel we should take the standard base > set of SEO best practices as core functionality, and make sure it is > extremely simple to override those parts, as our needs force us. I am > by no means an SEO expert, and thus won't voice my opinion on whether > breadcrumbs are better than direct product links. My concern is for > the architecture, and keeping spree a good base with which to start my > e-commerce solutions.
The flexible nature of Spree is what sets it apart IMO. We just need to be careful that the core is not so "bare-bones" because we've been too conservative about things which are difficult to add. I'm not saying breadcrumbs go in or out on this basis, just making the general point.
The spree-more (see other thread) will be a useful alternative but we're still going to have to make decisions there as well. With a spree-core, spree-more and dozens of extensions I think that's about as flexible as we want to make things.
In the case of the actual URL, I think we can easily accommodate the two styles (category info vs. no category info.) So that's probably a good starting point. I do think the "related product" links in Eliot's extension is quite nice. That's a bit marginal for core perhaps (based on what I'm hearing) but everyone should install this and see it if for themselves if they haven't already.
Anyways, nothing wrong with a lively discussion. We'll come up with a good compromise. Spree is ultimately about choices so we'll try to continue that tradition.
> SEO support should be included in the core, the technical aspects are > important; SEO as a whole is important. My experience is that the > majority of time proven SEO best practices are also about usability > and therefore important anyway, so I don't consider them as being > about SEO, but about best practices in general.
Cool. I agree :)
> Given the fluid and very specific needs of any given customer, one > cannot predict (beyond those core, time proven aspects) just what this > or that particular customer is going to want. If I have to tell my > customer that it'll take 5-10 hours to remove breadcrumbs from the > url, it's the same as if I have to tell them it'll take that time to > add breadcrumbs.
Yes, I agree. I would hope to come up with a solution that doesn't take 5-10 hours to remove breadcrumbs -- perhaps a configuration setting as previously suggested. I suppose I'm just used to dealing with an ecommerce system that has a lot of stuff floating around that's unused -- which has never been an issue IMO.
> I would rather see a system that allows me to quickly add or remove > breadcrumbs (or any other SEO functionality) as my client's needs > require. I see our extensions system as being the key to this. In > order to keep the core simple, I feel we should take the standard base > set of SEO best practices as core functionality, and make sure it is > extremely simple to override those parts, as our needs force us. I am > by no means an SEO expert, and thus won't voice my opinion on whether > breadcrumbs are better than direct product links. My concern is for > the architecture, and keeping spree a good base with which to start my > e-commerce solutions.
Again, I agree that Spree must have decent architecture to serve as a strong base. However, I suppose I'm a bit against the grain of the Spree community in that I think that Spree should contain more ecommerce features like user reviews, user account functionality (wishlists), landing pages, more CMS functionality, etc. etc. and have an easy way to disable or build upon this architecture. Wordpress serves as an example -- a simple wordpress theme contains ~10 views. The views can be edited to use existing functionality that comes with an out of the box wordpress install.
I think Spree could succeed similarly -- the set of rails views are always going to be overridden for a client and would require snippets to be added for the existing out of the box functionality (reviews, wishlist, etc). A Spree theme could also contain a set of views that correspond to user account or landing page functionality and these views can be included or excluded from the client theme. So, out of the box Spree functionality could be impressive, but the themes that use the out of the box functionality may range from simple to extensive.
I like our extension system too, but the ease at which multiple extensions can be integrated together remains untested and relatively undocumented. I'm currently working on a client that requires about 8 customization points -- rather than use several existing extensions & based on the limited budget, it's going to be easier for me to build one extension with the customization rather than figure out how all the extensions can play nice.
> --Christopher
I'd rather see the Spree core contain the spree-more functionality, but by default it's turned off & excluded from the views. Introducing the idea of a spree-core and spree-more to me simply means maintaining two sets of code base and managing all the opinions of which functionality should go in which spree repository.
Why not consider building a system that is more easily configurable with a full set of ecommerce features than maintaining two separate code bases? I realize this goes against the "convention over configuration" rails notion that Spree was originally based on, but IMO, Spree is going to more successful as a configurable, feature rich platform rather than an opinionated minimal-decisions-required software. I don't "want to go all Chuck Norris" on Spree, but an ecommerce platform audience of product marketing + business folks is very different from the Rails audience of developers. It serves me as a developer to have a platform that appeals to those other folks', at the end of the day I just want to code.
I agree with Steph on one level, but with Sean some other places, let
me attempt to elaborate:
From the early days of Spree, it was intended to be a no-fluff kind
of ecommerce system. We all could build web stores (or so we thought)
originally by following Agile Web Development for Rails from beginning
to end and get some basic store functionality. I haven't evaluated
Spree before now because it didn't do enough for me "out of the box"
to warrant me familiarizing myself with it, when I could use what I
had build on in the past.
Fast-forward to today, Spree core already has a lot of functionality
that I don't need (most things about variants, and the "every
inventory is a unique record" methods) and is missing a good bit of
functionality that I do need (some of which are found in extensions,
others not). While I do like the method of extending Spree to get it
to do what I want, I find that looking for well-working extensions is
much worse in practice than using your average Rails plugin.
Thus my idea for Spree-more is this:
1. Spree-core is developed as a lightweight cart with what most people
consider the minimum-needed to begin with.
2. Spree-more is spree-core plus extensions that many in the community
find useful.
3. Tests are written at the integration points, and when Spree-core
has some modifications, then we can run all the spree-core tests, and
then run the tests that verify breakage in functionality in any of
those select "more" extensions. This way you can cover at least most
of your bases as you are updating core. The purpose of this is that we
"must" keep core and more in sync with each other instead of trailing
off behind with various popular extensions not being able to work out
of the box.
IMO, saying that leaving features out of core is as important as what
to put in is very sketchy logic (please don't take that wrong, I don't
mean to be rude here). We all make decisions about what is right and
wrong SEO-wise, design-wise, else-wise and definitely all come to
different conclusions all the time, based mostly upon our clients'
needs. Convention over configuration can only go so far when starting
out a project, ultimately the whole Rails community is now excited
over "templates" which everyone needs to create when doing apps over
and over again gets repetitive.
This is my first foray into Spree, and I do appreciate all the work
that has gone into it thus far. I already have 3 extensions that I
plan to release back into the community when I am done, and these
aren't even the things I would like to see in core, but I would really
love to see the starting point of Spree installation to be a bit more
interesting, and full of pizazz than it is.
Timothy
On Jul 20, 2009, at 8:59 PM, Stephanie Powell wrote:
>> SEO support should be included in the core, the technical aspects
>> are
>> important; SEO as a whole is important. My experience is that the
>> majority of time proven SEO best practices are also about usability
>> and therefore important anyway, so I don't consider them as being
>> about SEO, but about best practices in general.
> Cool. I agree :)
>> Given the fluid and very specific needs of any given customer, one
>> cannot predict (beyond those core, time proven aspects) just what
>> this
>> or that particular customer is going to want. If I have to tell my
>> customer that it'll take 5-10 hours to remove breadcrumbs from the
>> url, it's the same as if I have to tell them it'll take that time to
>> add breadcrumbs.
> Yes, I agree. I would hope to come up with a solution that doesn't
> take
> 5-10 hours to remove breadcrumbs -- perhaps a configuration setting as
> previously suggested. I suppose I'm just used to dealing with an
> ecommerce system that has a lot of stuff floating around that's unused
> -- which has never been an issue IMO.
>> I would rather see a system that allows me to quickly add or remove
>> breadcrumbs (or any other SEO functionality) as my client's needs
>> require. I see our extensions system as being the key to this. In
>> order to keep the core simple, I feel we should take the standard
>> base
>> set of SEO best practices as core functionality, and make sure it is
>> extremely simple to override those parts, as our needs force us. I am
>> by no means an SEO expert, and thus won't voice my opinion on whether
>> breadcrumbs are better than direct product links. My concern is for
>> the architecture, and keeping spree a good base with which to start
>> my
>> e-commerce solutions.
> Again, I agree that Spree must have decent architecture to serve as a
> strong base. However, I suppose I'm a bit against the grain of the
> Spree
> community in that I think that Spree should contain more ecommerce
> features like user reviews, user account functionality (wishlists),
> landing pages, more CMS functionality, etc. etc. and have an easy
> way to
> disable or build upon this architecture. Wordpress serves as an
> example
> -- a simple wordpress theme contains ~10 views. The views can be
> edited > to use existing functionality that comes with an out of the box
> wordpress install.
> I think Spree could succeed similarly -- the set of rails views are
> always going to be overridden for a client and would require
> snippets to
> be added for the existing out of the box functionality (reviews,
> wishlist, etc). A Spree theme could also contain a set of views that
> correspond to user account or landing page functionality and these
> views
> can be included or excluded from the client theme. So, out of the box
> Spree functionality could be impressive, but the themes that use the
> out
> of the box functionality may range from simple to extensive.
> I like our extension system too, but the ease at which multiple
> extensions can be integrated together remains untested and relatively
> undocumented. I'm currently working on a client that requires about 8
> customization points -- rather than use several existing extensions &
> based on the limited budget, it's going to be easier for me to build
> one
> extension with the customization rather than figure out how all the
> extensions can play nice.
>> --Christopher
> I'd rather see the Spree core contain the spree-more functionality,
> but
> by default it's turned off & excluded from the views. Introducing the
> idea of a spree-core and spree-more to me simply means maintaining two
> sets of code base and managing all the opinions of which functionality
> should go in which spree repository.
> Why not consider building a system that is more easily configurable
> with
> a full set of ecommerce features than maintaining two separate code
> bases? I realize this goes against the "convention over configuration"
> rails notion that Spree was originally based on, but IMO, Spree is
> going
> to more successful as a configurable, feature rich platform rather
> than
> an opinionated minimal-decisions-required software. I don't "want to
> go
> all Chuck Norris" on Spree, but an ecommerce platform audience of
> product marketing + business folks is very different from the Rails
> audience of developers. It serves me as a developer to have a platform
> that appeals to those other folks', at the end of the day I just
> want to
> code.
These are all good comments but I think we should separate the "what
goes into spree-core" discussions on their own thread[1] and keep this
one to the specifics of the single product URL.
Getting back to the single product URL, I had lunch with a colleague
today and discussed the problem with him. He had an interesting
solution.
1.) Keep the category based URL's for browsing and use single product
URL for the actual "show" action. (So far nothing too controversial)
2.) Use the HTTP Referral information on the product page (which
contains the browsing hierarchy in the URL still) to render the
breadcrumbs.
3.) For caching purposes possibly generate the breadcrumbs using
javascript (progressive caching.)
#3 needs a little bit of testing and exploration. We're not doing a
lot with page caching in Spree right now but we need to start thinking
about that. IMO this solution works very nicely if you ignore caching
impact and possibly works with caching if we can get the referral
information in JS.
On Mon, Jul 20, 2009 at 11:26 PM, Timothy Johnson<jhnsntm...@gmail.com> wrote:
> I agree with Steph on one level, but with Sean some other places, let me
> attempt to elaborate:
> From the early days of Spree, it was intended to be a no-fluff kind of
> ecommerce system. We all could build web stores (or so we thought)
> originally by following Agile Web Development for Rails from beginning to
> end and get some basic store functionality. I haven't evaluated Spree before
> now because it didn't do enough for me "out of the box" to warrant me
> familiarizing myself with it, when I could use what I had build on in the
> past.
> Fast-forward to today, Spree core already has a lot of functionality that I
> don't need (most things about variants, and the "every inventory is a unique
> record" methods) and is missing a good bit of functionality that I do need
> (some of which are found in extensions, others not). While I do like the
> method of extending Spree to get it to do what I want, I find that looking
> for well-working extensions is much worse in practice than using your
> average Rails plugin.
> Thus my idea for Spree-more is this:
> 1. Spree-core is developed as a lightweight cart with what most people
> consider the minimum-needed to begin with.
> 2. Spree-more is spree-core plus extensions that many in the community find
> useful.
> 3. Tests are written at the integration points, and when Spree-core has some
> modifications, then we can run all the spree-core tests, and then run the
> tests that verify breakage in functionality in any of those select "more"
> extensions. This way you can cover at least most of your bases as you are
> updating core. The purpose of this is that we "must" keep core and more in
> sync with each other instead of trailing off behind with various popular
> extensions not being able to work out of the box.
> IMO, saying that leaving features out of core is as important as what to put
> in is very sketchy logic (please don't take that wrong, I don't mean to be
> rude here). We all make decisions about what is right and wrong SEO-wise,
> design-wise, else-wise and definitely all come to different conclusions all
> the time, based mostly upon our clients' needs. Convention over
> configuration can only go so far when starting out a project, ultimately the
> whole Rails community is now excited over "templates" which everyone needs
> to create when doing apps over and over again gets repetitive.
> This is my first foray into Spree, and I do appreciate all the work that has
> gone into it thus far. I already have 3 extensions that I plan to release
> back into the community when I am done, and these aren't even the things I
> would like to see in core, but I would really love to see the starting point
> of Spree installation to be a bit more interesting, and full of pizazz than
> it is.
> Timothy
> On Jul 20, 2009, at 8:59 PM, Stephanie Powell wrote:
> Hi,
> I apologize for being unclear..
> SEO support should be included in the core, the technical aspects are
> important; SEO as a whole is important. My experience is that the
> majority of time proven SEO best practices are also about usability
> and therefore important anyway, so I don't consider them as being
> about SEO, but about best practices in general.
> Cool. I agree :)
> Given the fluid and very specific needs of any given customer, one
> cannot predict (beyond those core, time proven aspects) just what this
> or that particular customer is going to want. If I have to tell my
> customer that it'll take 5-10 hours to remove breadcrumbs from the
> url, it's the same as if I have to tell them it'll take that time to
> add breadcrumbs.
> Yes, I agree. I would hope to come up with a solution that doesn't take
> 5-10 hours to remove breadcrumbs -- perhaps a configuration setting as
> previously suggested. I suppose I'm just used to dealing with an
> ecommerce system that has a lot of stuff floating around that's unused
> -- which has never been an issue IMO.
> I would rather see a system that allows me to quickly add or remove
> breadcrumbs (or any other SEO functionality) as my client's needs
> require. I see our extensions system as being the key to this. In
> order to keep the core simple, I feel we should take the standard base
> set of SEO best practices as core functionality, and make sure it is
> extremely simple to override those parts, as our needs force us. I am
> by no means an SEO expert, and thus won't voice my opinion on whether
> breadcrumbs are better than direct product links. My concern is for
> the architecture, and keeping spree a good base with which to start my
> e-commerce solutions.
> Again, I agree that Spree must have decent architecture to serve as a
> strong base. However, I suppose I'm a bit against the grain of the Spree
> community in that I think that Spree should contain more ecommerce
> features like user reviews, user account functionality (wishlists),
> landing pages, more CMS functionality, etc. etc. and have an easy way to
> disable or build upon this architecture. Wordpress serves as an example
> -- a simple wordpress theme contains ~10 views. The views can be edited
> to use existing functionality that comes with an out of the box
> wordpress install.
> I think Spree could succeed similarly -- the set of rails views are
> always going to be overridden for a client and would require snippets to
> be added for the existing out of the box functionality (reviews,
> wishlist, etc). A Spree theme could also contain a set of views that
> correspond to user account or landing page functionality and these views
> can be included or excluded from the client theme. So, out of the box
> Spree functionality could be impressive, but the themes that use the out
> of the box functionality may range from simple to extensive.
> I like our extension system too, but the ease at which multiple
> extensions can be integrated together remains untested and relatively
> undocumented. I'm currently working on a client that requires about 8
> customization points -- rather than use several existing extensions &
> based on the limited budget, it's going to be easier for me to build one
> extension with the customization rather than figure out how all the
> extensions can play nice.
> --Christopher
> I'd rather see the Spree core contain the spree-more functionality, but
> by default it's turned off & excluded from the views. Introducing the
> idea of a spree-core and spree-more to me simply means maintaining two
> sets of code base and managing all the opinions of which functionality
> should go in which spree repository.
> Why not consider building a system that is more easily configurable with
> a full set of ecommerce features than maintaining two separate code
> bases? I realize this goes against the "convention over configuration"
> rails notion that Spree was originally based on, but IMO, Spree is going
> to more successful as a configurable, feature rich platform rather than
> an opinionated minimal-decisions-required software. I don't "want to go
> all Chuck Norris" on Spree, but an ecommerce platform audience of
> product marketing + business folks is very different from the Rails
> audience of developers. It serves me as a developer to have a platform
> that appeals to those other folks', at the end of the day I just want to
> code.
> 1.) Keep the category based URL's for browsing and use single product > URL for the actual "show" action. (So far nothing too controversial)
This is the best way to ensure single product URLs, IMHO.
> 2.) Use the HTTP Referral information on the product page (which > contains the browsing hierarchy in the URL still) to render the > breadcrumbs.
+1
> 3.) For caching purposes possibly generate the breadcrumbs using > javascript (progressive caching.)
Not needed and unnecessarily introduces JS dependencies. Being able to walk the taxon tree from any given child node up to top parent should be simple enough. Perhaps consider acts_as_nested_set over acts_as_adjacency_list?
I like this, but wonder about the issue following...
What if we implement search and get to a product page from search
results?
What if the user bookmarks it, or is coming from a link in another
website directly to the product show page?
Those 2 issues illustrate why it "may" be a good idea to have a
"primary" taxonomy for each product. Just a boolean field in the join
model maybe that flags it as "primary categorization"?
timothy
On Jul 21, 2009, at 12:57 PM, Sean Schofield wrote:
> These are all good comments but I think we should separate the "what
> goes into spree-core" discussions on their own thread[1] and keep this
> one to the specifics of the single product URL.
> Getting back to the single product URL, I had lunch with a colleague
> today and discussed the problem with him. He had an interesting
> solution.
> 1.) Keep the category based URL's for browsing and use single product
> URL for the actual "show" action. (So far nothing too controversial)
> 2.) Use the HTTP Referral information on the product page (which
> contains the browsing hierarchy in the URL still) to render the
> breadcrumbs.
> 3.) For caching purposes possibly generate the breadcrumbs using
> javascript (progressive caching.)
> #3 needs a little bit of testing and exploration. We're not doing a
> lot with page caching in Spree right now but we need to start thinking
> about that. IMO this solution works very nicely if you ignore caching
> impact and possibly works with caching if we can get the referral
> information in JS.
> On Mon, Jul 20, 2009 at 11:26 PM, Timothy
> Johnson<jhnsntm...@gmail.com> wrote:
>> I agree with Steph on one level, but with Sean some other places,
>> let me
>> attempt to elaborate:
>> From the early days of Spree, it was intended to be a no-fluff kind
>> of
>> ecommerce system. We all could build web stores (or so we thought)
>> originally by following Agile Web Development for Rails from
>> beginning to
>> end and get some basic store functionality. I haven't evaluated
>> Spree before
>> now because it didn't do enough for me "out of the box" to warrant me
>> familiarizing myself with it, when I could use what I had build on
>> in the
>> past.
>> Fast-forward to today, Spree core already has a lot of
>> functionality that I
>> don't need (most things about variants, and the "every inventory is
>> a unique
>> record" methods) and is missing a good bit of functionality that I
>> do need
>> (some of which are found in extensions, others not). While I do
>> like the
>> method of extending Spree to get it to do what I want, I find that
>> looking
>> for well-working extensions is much worse in practice than using your
>> average Rails plugin.
>> Thus my idea for Spree-more is this:
>> 1. Spree-core is developed as a lightweight cart with what most
>> people
>> consider the minimum-needed to begin with.
>> 2. Spree-more is spree-core plus extensions that many in the
>> community find
>> useful.
>> 3. Tests are written at the integration points, and when Spree-core
>> has some
>> modifications, then we can run all the spree-core tests, and then
>> run the
>> tests that verify breakage in functionality in any of those select
>> "more"
>> extensions. This way you can cover at least most of your bases as
>> you are
>> updating core. The purpose of this is that we "must" keep core and
>> more in
>> sync with each other instead of trailing off behind with various
>> popular
>> extensions not being able to work out of the box.
>> IMO, saying that leaving features out of core is as important as
>> what to put
>> in is very sketchy logic (please don't take that wrong, I don't
>> mean to be
>> rude here). We all make decisions about what is right and wrong SEO- >> wise,
>> design-wise, else-wise and definitely all come to different
>> conclusions all
>> the time, based mostly upon our clients' needs. Convention over
>> configuration can only go so far when starting out a project,
>> ultimately the
>> whole Rails community is now excited over "templates" which
>> everyone needs
>> to create when doing apps over and over again gets repetitive.
>> This is my first foray into Spree, and I do appreciate all the work
>> that has
>> gone into it thus far. I already have 3 extensions that I plan to
>> release
>> back into the community when I am done, and these aren't even the
>> things I
>> would like to see in core, but I would really love to see the
>> starting point
>> of Spree installation to be a bit more interesting, and full of
>> pizazz than
>> it is.
>> Timothy
>> On Jul 20, 2009, at 8:59 PM, Stephanie Powell wrote:
>> Hi,
>> I apologize for being unclear..
>> SEO support should be included in the core, the technical aspects
>> are
>> important; SEO as a whole is important. My experience is that the
>> majority of time proven SEO best practices are also about usability
>> and therefore important anyway, so I don't consider them as being
>> about SEO, but about best practices in general.
>> Cool. I agree :)
>> Given the fluid and very specific needs of any given customer, one
>> cannot predict (beyond those core, time proven aspects) just what
>> this
>> or that particular customer is going to want. If I have to tell my
>> customer that it'll take 5-10 hours to remove breadcrumbs from the
>> url, it's the same as if I have to tell them it'll take that time to
>> add breadcrumbs.
>> Yes, I agree. I would hope to come up with a solution that doesn't
>> take
>> 5-10 hours to remove breadcrumbs -- perhaps a configuration setting
>> as
>> previously suggested. I suppose I'm just used to dealing with an
>> ecommerce system that has a lot of stuff floating around that's
>> unused
>> -- which has never been an issue IMO.
>> I would rather see a system that allows me to quickly add or remove
>> breadcrumbs (or any other SEO functionality) as my client's needs
>> require. I see our extensions system as being the key to this. In
>> order to keep the core simple, I feel we should take the standard
>> base
>> set of SEO best practices as core functionality, and make sure it is
>> extremely simple to override those parts, as our needs force us. I am
>> by no means an SEO expert, and thus won't voice my opinion on whether
>> breadcrumbs are better than direct product links. My concern is for
>> the architecture, and keeping spree a good base with which to start
>> my
>> e-commerce solutions.
>> Again, I agree that Spree must have decent architecture to serve as a
>> strong base. However, I suppose I'm a bit against the grain of the
>> Spree
>> community in that I think that Spree should contain more ecommerce
>> features like user reviews, user account functionality (wishlists),
>> landing pages, more CMS functionality, etc. etc. and have an easy
>> way to
>> disable or build upon this architecture. Wordpress serves as an
>> example
>> -- a simple wordpress theme contains ~10 views. The views can be
>> edited
>> to use existing functionality that comes with an out of the box
>> wordpress install.
>> I think Spree could succeed similarly -- the set of rails views are
>> always going to be overridden for a client and would require
>> snippets to
>> be added for the existing out of the box functionality (reviews,
>> wishlist, etc). A Spree theme could also contain a set of views that
>> correspond to user account or landing page functionality and these
>> views
>> can be included or excluded from the client theme. So, out of the box
>> Spree functionality could be impressive, but the themes that use
>> the out
>> of the box functionality may range from simple to extensive.
>> I like our extension system too, but the ease at which multiple
>> extensions can be integrated together remains untested and relatively
>> undocumented. I'm currently working on a client that requires about 8
>> customization points -- rather than use several existing extensions &
>> based on the limited budget, it's going to be easier for me to
>> build one
>> extension with the customization rather than figure out how all the
>> extensions can play nice.
>> --Christopher
>> I'd rather see the Spree core contain the spree-more functionality,
>> but
>> by default it's turned off & excluded from the views. Introducing the
>> idea of a spree-core and spree-more to me simply means maintaining
>> two
>> sets of code base and managing all the opinions of which
>> functionality
>> should go in which spree repository.
>> Why not consider building a system that is more easily configurable
>> with
>> a full set of ecommerce features than maintaining two separate code
>> bases? I realize this goes against the "convention over
>> configuration"
>> rails notion that Spree was originally based on, but IMO, Spree is
>> going
>> to more successful as a configurable, feature rich platform rather
>> than
>> an opinionated minimal-decisions-required software. I don't "want
>> to go
>> all Chuck Norris" on Spree, but an ecommerce platform audience of
>> product marketing + business folks is very different from the Rails
>> audience of developers. It serves me as a developer to have a
>> platform
>> that appeals to those other folks', at the end of the day I just
>> want to
>> code.
When I've implemented this for a client before, we used javascript cookies to track the navigation. If a user came directly to the site or by some other means, the product had a primary taxonomy that was used for the breadcrumb display if the cookie was undefined. The javascript was simple and unobtrusive.
For another client, I used a single session variable to track the navigation history to generate breadcrumbs in taxonomy + search plus search refinement. The tracker variable will be used on the product page to generate the breadcrumb that will include either the taxonomy history or the search + refinement history to enable the user to navigate back to browse taxonomies or their search history.
I know one of the comments was to not be dependent on javascript. For the latter client mentioned above, javascript was not required and a single session variable contained all the relevant breadcrumb information. As I said before, another potential solution is to use the '#' to append breadcrumb / navigation information. This is more visible to a user, but not visible to search engines.
Timothy Johnson wrote:
> I like this, but wonder about the issue following...
> What if we implement search and get to a product page from search results?
> What if the user bookmarks it, or is coming from a link in another > website directly to the product show page?
> Those 2 issues illustrate why it "may" be a good idea to have a > "primary" taxonomy for each product. Just a boolean field in the join > model maybe that flags it as "primary categorization"?
> timothy
> On Jul 21, 2009, at 12:57 PM, Sean Schofield wrote:
>> These are all good comments but I think we should separate the "what
>> goes into spree-core" discussions on their own thread[1] and keep this
>> one to the specifics of the single product URL.
>> Getting back to the single product URL, I had lunch with a colleague
>> today and discussed the problem with him. He had an interesting
>> solution.
>> 1.) Keep the category based URL's for browsing and use single product
>> URL for the actual "show" action. (So far nothing too controversial)
>> 2.) Use the HTTP Referral information on the product page (which
>> contains the browsing hierarchy in the URL still) to render the
>> breadcrumbs.
>> 3.) For caching purposes possibly generate the breadcrumbs using
>> javascript (progressive caching.)
>> #3 needs a little bit of testing and exploration. We're not doing a
>> lot with page caching in Spree right now but we need to start thinking
>> about that. IMO this solution works very nicely if you ignore caching
>> impact and possibly works with caching if we can get the referral
>> information in JS.
>> On Mon, Jul 20, 2009 at 11:26 PM, Timothy >> Johnson<jhnsntm...@gmail.com <mailto:jhnsntm...@gmail.com>> wrote:
>>> I agree with Steph on one level, but with Sean some other places, let me
>>> attempt to elaborate:
>>> From the early days of Spree, it was intended to be a no-fluff kind of
>>> ecommerce system. We all could build web stores (or so we thought)
>>> originally by following Agile Web Development for Rails from >>> beginning to
>>> end and get some basic store functionality. I haven't evaluated >>> Spree before
>>> now because it didn't do enough for me "out of the box" to warrant me
>>> familiarizing myself with it, when I could use what I had build on >>> in the
>>> past.
>>> Fast-forward to today, Spree core already has a lot of functionality >>> that I
>>> don't need (most things about variants, and the "every inventory is >>> a unique
>>> record" methods) and is missing a good bit of functionality that I >>> do need
>>> (some of which are found in extensions, others not). While I do like the
>>> method of extending Spree to get it to do what I want, I find that >>> looking
>>> for well-working extensions is much worse in practice than using your
>>> average Rails plugin.
>>> Thus my idea for Spree-more is this:
>>> 1. Spree-core is developed as a lightweight cart with what most people
>>> consider the minimum-needed to begin with.
>>> 2. Spree-more is spree-core plus extensions that many in the >>> community find
>>> useful.
>>> 3. Tests are written at the integration points, and when Spree-core >>> has some
>>> modifications, then we can run all the spree-core tests, and then >>> run the
>>> tests that verify breakage in functionality in any of those select >>> "more"
>>> extensions. This way you can cover at least most of your bases as >>> you are
>>> updating core. The purpose of this is that we "must" keep core and >>> more in
>>> sync with each other instead of trailing off behind with various popular
>>> extensions not being able to work out of the box.
>>> IMO, saying that leaving features out of core is as important as >>> what to put
>>> in is very sketchy logic (please don't take that wrong, I don't mean >>> to be
>>> rude here). We all make decisions about what is right and wrong >>> SEO-wise,
>>> design-wise, else-wise and definitely all come to different >>> conclusions all
>>> the time, based mostly upon our clients' needs. Convention over
>>> configuration can only go so far when starting out a project, >>> ultimately the
>>> whole Rails community is now excited over "templates" which everyone >>> needs
>>> to create when doing apps over and over again gets repetitive.
>>> This is my first foray into Spree, and I do appreciate all the work >>> that has
>>> gone into it thus far. I already have 3 extensions that I plan to >>> release
>>> back into the community when I am done, and these aren't even the >>> things I
>>> would like to see in core, but I would really love to see the >>> starting point
>>> of Spree installation to be a bit more interesting, and full of >>> pizazz than
>>> it is.
>>> Timothy
>>> On Jul 20, 2009, at 8:59 PM, Stephanie Powell wrote:
>>> Hi,
>>> I apologize for being unclear..
>>> SEO support should be included in the core, the technical aspects are
>>> important; SEO as a whole is important. My experience is that the
>>> majority of time proven SEO best practices are also about usability
>>> and therefore important anyway, so I don't consider them as being
>>> about SEO, but about best practices in general.
>>> Cool. I agree :)
>>> Given the fluid and very specific needs of any given customer, one
>>> cannot predict (beyond those core, time proven aspects) just what this
>>> or that particular customer is going to want. If I have to tell my
>>> customer that it'll take 5-10 hours to remove breadcrumbs from the
>>> url, it's the same as if I have to tell them it'll take that time to
>>> add breadcrumbs.
>>> Yes, I agree. I would hope to come up with a solution that doesn't take
>>> 5-10 hours to remove breadcrumbs -- perhaps a configuration setting as
>>> previously suggested. I suppose I'm just used to dealing with an
>>> ecommerce system that has a lot of stuff floating around that's unused
>>> -- which has never been an issue IMO.
>>> I would rather see a system that allows me to quickly add or remove
>>> breadcrumbs (or any other SEO functionality) as my client's needs
>>> require. I see our extensions system as being the key to this. In
>>> order to keep the core simple, I feel we should take the standard base
>>> set of SEO best practices as core functionality, and make sure it is
>>> extremely simple to override those parts, as our needs force us. I am
>>> by no means an SEO expert, and thus won't voice my opinion on whether
>>> breadcrumbs are better than direct product links. My concern is for
>>> the architecture, and keeping spree a good base with which to start my
>>> e-commerce solutions.
>>> Again, I agree that Spree must have decent architecture to serve as a
>>> strong base. However, I suppose I'm a bit against the grain of the Spree
>>> community in that I think that Spree should contain more ecommerce
>>> features like user reviews, user account functionality (wishlists),
>>> landing pages, more CMS functionality, etc. etc. and have an easy way to
>>> disable or build upon this architecture. Wordpress serves as an example
>>> -- a simple wordpress theme contains ~10 views. The views can be edited
>>> to use existing functionality that comes with an out of the box
>>> wordpress install.
>>> I think Spree could succeed similarly -- the set of rails views are
>>> always going to be overridden for a client and would require snippets to
>>> be added for the existing out of the box functionality (reviews,
>>> wishlist, etc). A Spree theme could also contain a set of views that
>>> correspond to user account or landing page functionality and these views
>>> can be included or excluded from the client theme. So, out of the box
>>> Spree functionality could be impressive, but the themes that use the out
>>> of the box functionality may range from simple to extensive.
>>> I like our extension system too, but the ease at which multiple
>>> extensions can be integrated together remains untested and relatively
>>> undocumented. I'm currently working on a client that requires about 8
>>> customization points -- rather than use several existing extensions &
>>> based on the limited budget, it's going to be easier for me to build one
>>> extension with the customization rather than figure out how all the
>>> extensions can play nice.
>>> --Christopher
>>> I'd rather see the Spree core contain the spree-more functionality, but
>>> by
