add new sorting features

[Armadill0]

There always are feature requests to easy reorder tasks on the lists.

But we have several problems:

• currently there is no order for the tasks saved in the database
• tasks are sorted via the last update timestamp (except the cover view, which only has open tasks)
• there are already the scrollable list and the context menu as touch interactions, another touch interaction could be difficult to use and implement

Possible solutions:

• Push task to the top of the list by updating the last updated timestamp
• implement a drag'n'drop reordering in a separate dialog (this would need need a complete refactoring of the task ordering because of the current order behaviour mentioned above int he first problem)

[mxwell]

I think the 'priority' property is a natural way to sort tasks in a list. The most important tasks are always on the top, less important ones are lower. The only case when you need a different sorting is to view tasks in the chronological order of a due date. But it might be done better with smart lists like 'Till today', 'Till tomorrow' and so on (when tasks will have a property 'due date').

[Armadill0]

Using a priority seems to be a good feature. But I like the current ordering by last update very much. We should implement several order mechanisms to allow the user to select between them or combine them.

The following orders could be useful:

• alphabetically
• creation date
• last update
• priority

Therefor the priority could always be the primary sorting order and the second one could be chosen between the others. Some sort of invert option could also be added for the second order type.

[Armadill0]

Multi column sorting can be done with a custom QSortFilterProxyModel in Qt.

Examples:

• https://github.com/CODeRUS/harbour-mitakuuluu2/blob/master/client/src/contactsfiltermodel.cpp#L30
• http://www.dayofthenewdan.com/2013/02/09/Qt_QSortFilterProxyModel.html
• http://doc.qt.io/qt-5/qsortfilterproxymodel.html

Sorting columns should be task status and priority descending as primary sort attributes. Secondary and tertiary attributes could be alphabetically, creation date and/or last update. All of them should be choosable by the user in the settings.

[mxwell]

IMHO the very reason to have priorities is to sort your lists. If a task has a big priority, then it should be pinned at the top, at the most visible place. If you like to have you tasks sorted in any other order, you could simply ignore this feature and give them the same priority, i.e. leave the default. Please share your thoughts on preferred order in task lists.

It's also nice to have some noticeable emphasis on tasks with bigger priority, because now priority is hardly noticeable (I overlooked it after switch to mainstream version until experimenting with priorities). How could priorities be communicated to a user in TaskPage? There are several alternatives: additional text (the current state), sizes, some elements or colors.

As I said the current textual representation doesn't strike the eye. Be it done in another way, it would make a task item too heavy. While the main textual message of a task item is the name of the task.

Sizes: I don't like the idea to make task items various in sizes. It destroys the uniformity.

My solution is to add smallest possible elements with bright colors. This idea is closely related to small set of available priorities, that could be easily translated into colored elements:

0 - "No priority" or "I don't care about priority" - task item doesn't have any elements of priority
1 - "Low priority" - task item has an element with a neutral color
2 - "Medium priority" - task item has an element with a stronger color
3 - "Very important and urgent task" - task item has an element with the brightest color

(Actually I doubt need in the option 2 - the simpler is the better).

Bright colors are good to give emphasis, even though style guides don't recommend hardcoded colors. I'd like to know your opinion on how priority representation could be improved.

[Armadill0]

Thanks for sharing your thoughts. 😄

sorting orders

As I said in my last post, my preferred sorting order would be:
1.) the task status (to always have the undone takss at the top)
2.) the priority (because priority only makes sense if you always sort the tasks with it, as you already said)
3.) additional user selectable parameters (alphabetically, last update, ...) with "last update" as default
This order behaviour will give the user the possibility to choose from different order behaviours and to use the priority if he wants to (many users don't use priorities I think). Sometimes you need alternative sortings to have a quick overview about your tasks.
Just to clarify: The first two parameters should be hardcoded while only the last one is changeable by the user.
I hope it is clear what I want to achieve with this. If not, feel free to poke me. 😉

priority levels

The current priority has 5 levels in total. The reason why I changed this from your implementation was that I hate priorities which only have one direction (normal, important, more important,...) This is always a problem, if you already have some tasks which have to be done, but you want to add a task which has a lower priority than any other currently existing tasks. This is why I set the default priority to 3. From this default priority the user can mark tasks as important or even more important than important tasks and vice versa with "negative" priority.
I think this system has much more flexibility for the user's needs, which is why I want to keep it. What do you think about this?

priority representation

First: I'm with you, that colors are a very good representation for priorities. The only reason I removed the colors were the design guidelines and I'm afraid that if a user e.g. has a bright red ambience loaded, that high priority tasks, which sure have the red color, are being forgotten.
To be honest, I don't think the current representation is the best. I experimented with many different things, but I haven't found a great solution which is color independent.
I have some new suggestions, but this is a really difficult topic. I opened a separate issue to discuss this: #60