Improve category handling: request for feedback

[Maik Hoepfel]

Hi all,

I get to work on improving category handling in Oscar. I made a sort of plan of action here: https://github.com/django-oscar/django-oscar/issues/1670

So now is a good time to raise any annoyances you have with Oscar's category handling, or any thoughts you have :) Please reply here.

Cheers,

Maik

[Markus Bertheau]

I would not invest too much time working around MySQL limitations and just recommend PostgreSQL if you anticipate long slugs, similarly to how Django recommends PostgreSQL. However, the failure with slugs that are too long should be loud and clear.

No other thoughts on that matter :)

Buon carnevale!

Markus

[Joshua Wedekind]

I don't like how categories work in Oscar mainly because I don't understand how they work. (Great argument, eh?)

Is the structure of categories based off parsing a string of text? I'm no expert, but that seems like a bad way to implement a tree structure. (Again, I'm NOT an expert--going off intuition here).

Ideally, I'd like every category to have a parent_id, and have the full name, slug, et al generated by the implied structure. But I don't know what kind of architectural or performance issues might arise.

For example, instead of:

id	name	slug	full_name
1	Clothing	clothing/	Clothing
2	Men's	clothing/mens	Clothing > Men's
3	Shirts	clothing/mens/shirts	Clothing > Men's > Shirts

I would prefer:

id	parent_id	name	slug
1	NULL	Clothing	clothing
2	1	Men's	mens
3	2	Shirts	shirts

Then, create an algorithm that loops up through parent categories to generate the complete slug, etc.

Again, I imagine this could cause a performance hit, and I'm not sure what architectural changes it would imply. But it seems like it'd nice.

[Joshua Wedekind]

Not too fond of the idea of dropping MySQL support.

I don't know how easy it would be for us to find PostgreSQL experts should the need arise, and no one in my entire team is familiar with PostgreSQL.

Maybe I should work on changing that--have any good book recommendations?

~Josh

[Markus Bertheau]

Just to be clear, I didn't mean that MySQL support should be dropped. It should be kept with the current limitations (see https://github.com/django-oscar/django-oscar/issues/1119), the limitations should be documented, and when the limit is hit, the failure should be loud and clear.

:)

Markus

[Maik Hoepfel]

Joshua, 

I think I pretty much implemented what you suggested in https://github.com/django-oscar/django-oscar/pull/1674. Feedback welcome! That should resolve the MySQL issue nicely, as it removes all the denormalisation and should make categories easier to think about.

Regards,

Maik

--
https://github.com/tangentlabs/django-oscar
http://django-oscar.readthedocs.org/en/latest/
https://twitter.com/django_oscar
---
You received this message because you are subscribed to the Google Groups "django-oscar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.

To view this discussion on the web, visit https://groups.google.com/d/msgid/django-oscar/b90ccad0-d5f3-46ef-926d-ea87b745a1f6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Valery Sorokin]

Nice to hear about ongoing categories handling redesign. Wish to share
some thoughts on it.

At the moment Oscar used the most appropriate, most efficient approach
to handle hierarchical taxonomy - treebeard with
materialized path. It allows to build menus and breadcrumbs very easy,
operate large taxonomies and is the fastest in the class. The approach
with parent_id will perform very slow even with few dozens of
categories. I'm sure we shouldn't change anything here.

On the other side the dashboard usability can be much improved. Below
is the list of some suggestions for the best user experience as I see
it.

# Category Management

/dashboard/catalogue/categories

Suggested layout/controls/behavior:

- Selectable (collapsible/expandable) hierarchical tree on the left hand panel
- Form set corresponding to the selected item on the tabbed main panel
- Radios (not dropdown box!) to make category active/inactive, hidden/visible
- Drag and drop to rearrange and promote/demote category tree items
(would be very nice to have)

The main idea is the hierarchical category tree should be visualized
somehow. The current Oscar approach with one level list and "First
child of"-like things is contra-intuitive for most people.

# List of the product

/dashboard/catalogue/categories/XXXXXXXXXX/update/

It's logical to display products that belong to particular categories
on this category detail page.

- Display list of products for the selected category on one of the tabs
- Typeahead search box to add new product to category

# Slugs

Slugs should NOT be filled automatically by default! The user should
be prompted to fill it either manually or automatically by clicking
button "Slugify" displayed next to the "Slug" text box. Clicking the
button will make AJAX call to appropriate function and fill the field.
User should have a choice.

Transliteration of non-latin based languages is different for English,
German, French etc. Because of this it should be possible to assign
individual slugify function to each language.

- Manually fill slug field by default
- AJAX-based automatic slugify on request ("Slugify" button)
- Allow separate slugify function per language

All of this is also true for handling product slugs (and other slugs too).

# Translations

The easiest way to manage translations seems to install
modeltranslation app. Drawback - no control of how to display
translatable fields. It's not possible to display all localized fields
at the same time.

There are also a pair of packages that can export selected model data
in the format that is picked by makemessages command. All the
following is then done using standard gettext/django-i18n environment.

Another approach is to add lang_id field to category table as the
second primary key. It gives much more freedom to layout dashboard.
For example all translatable fields for all language could be
displayed at the same time. But I'm afraid this idea won't be accepted
for the core.

One more method is to add additional fields with language suffix (ie
_de, _fr) to overridden model. A small function in Utils class will
serve field value in active language. Full freedom what to display and
how to layout. No dependency on modeltranslation package. Do we need a
small function in core that will cover all model translation issues?


# Product list

/dashboard/catalogue

The product list page should have:

- A typeahead textbox to filter products by category

Next to the UPC and Product title search boxes. It should be typeahead
box (as on the product page / category assignment tab). Dropdown box
won't work with more then a few hundreds categories.


# Assigning categories to product

/dashboard/catalogue/products/XXXXXXXXXXXX

The current form is not that bad (typeahead is always welcomed) but
will work only with small category tree. When you have to operate more
then hundred categories it becomes difficult/impossible to keep them
all in head. The big category tree should be visualized.

For assigning categories to product I suggest to use:

- Collapsible/expandable hierarchical tree with checkboxes on product
category tab main panel

Even better to back such a tree with AJAX to support large taxonomies.
There are a few nice jquery plugins for that.

http://www.jqueryrain.com/demo/jquery-treeview/


# Additional Category Fields

I think category model misses some standard fields. It's hard to
imagine a shop that could operate without making some category
active/inactive and hidden/visible. I suggest to include appropriate
fields in the core.

- Active/Inactive boolean field (checkbox or radio not dropdown box)
- Hidden/Visible boolean field (checkbox or radio not dropdown box)

The same is true for products.

# Some Snapshots

To illustrate some of the suggestions above I add here a few screen
snapshots from well known e-commerce platform. I'm not a fan of this
platform. Rather the opposite. I also don't think that suggested UI
patterns can be somehow linked to this particular platform. Obviously
they all are absolutely neutral. The only reason I used those
snapshots here is a luck of time to draw wireframes myself.

https://drive.google.com/open?id=0B2wa6361NG6OS2syU2ZLQ2Jhb0U&authuser=0

https://drive.google.com/open?id=0B2wa6361NG6OVldyS0k3a212Rnc&authuser=0

https://drive.google.com/open?id=0B2wa6361NG6OYjg3NExrcldNd1E&authuser=0

https://drive.google.com/open?id=0B2wa6361NG6OWFRqV2g5eDNjRjg&authuser=0

https://drive.google.com/open?id=0B2wa6361NG6OUGZsamd5TGF5aFU&authuser=0

https://drive.google.com/open?id=0B2wa6361NG6ONURBQ0pMREk3V2s&authuser=0

> https://groups.google.com/d/msgid/django-oscar/CALA313_0B-LcB3bJCpzZ3hdxmqECyqCS8zgjGamWnyc-fVatGw%40mail.gmail.com.

[BugSpencer]

Il giorno sabato 21 febbraio 2015 03:26:01 UTC+1, Valery Sorokin ha scritto:

 

# Translations

The easiest way to manage translations seems to install
modeltranslation app. Drawback - no control of how to display
translatable fields. It's not possible to display all localized fields
at the same time.

Just a note here: it is definitely possible to display multiple translation fields automatically in forms
with django-modeltranslation: you have to make apps.dashboard.catalogue.forms.BaseCategoryForm
subclass one of their mixins, or maybe just manually add "name_en", "name_de", "name_<whatever>"
to Meta.fields.

Anyway, I agree on modeltranslation being the easiest package to integrate translation into Oscar,
since hvad/parler-like approach will require to fork more and more parts of Oscar to make it work.

[That said I like the translations-in-a-separate-table approach more, and it would be great to have
it directly in Oscar core, but I think it will never happen, since at least having translations or not is
domain-specific, and this is not the right place to discuss about it]

[Maik Hoepfel]

Just a note that I merged the category branch now. Will be released as Oscar 1.1.

--
https://github.com/tangentlabs/django-oscar
http://django-oscar.readthedocs.org/en/latest/
https://twitter.com/django_oscar
---
You received this message because you are subscribed to the Google Groups "django-oscar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.

To view this discussion on the web, visit https://groups.google.com/d/msgid/django-oscar/d6f6d75b-508b-487f-af6f-648e7ae8799c%40googlegroups.com.