I’ve found that many actions I perform in the browser deal with notes rather than cards, primarily editing, and obviously, it’s much more useful to have the rows correspond to notes in these cases.
Now, I’m interested in hearing how (and maybe if) you would use this feature and what behaviour you would expect from it. I’m especially uncertain about which columns should be available. Of the current ones, there are only 5 that display note data: notetype, sort field, tags, created and modified.
For the rest, one card per note would have to be chosen to display its data. If that’s always the first one, that’d be easy. Making it customisable could be tricky.
So would it actually be useful to enable card columns in the notes view? Or do you have other columns in mind that should be available in the new mode?
I like it!
How about a column show how many cards this note created? e.g. Cloze note may create more than one cards.
===== Update =====
Another idea,
Group cards derive from same note together, like expand/collapse icon in PyCharm.
e.g. these 2 cloze cards derive from same note, so we can add a + before the first one, and hide the second. If we want to see the second, just click +.
@zhushenli
I really like the idea of showing the amount of cards generated. I think even showing the template names of the cards generated (or possible the indices, because the names might be too long?) might prove useful, and I’d certainly use it.
Some other columns I’d find useful would be min/max/avg of card values. Columns I would certainly use are “Most recent review of a card of this note” or “Average interval”
By cards values I mean all of those numeric / date values that cards are associated with, where the note could show their minimum / maximum / average value. For example, interval, review date, due date. Not all of them would be helpful, but some of them. I listed two that I would personally find valuable above.
@zhushenli, Qt doesn’t support something like this, so it couldn’t be done easily. And regardless of the framework: How would columns work if there are two different objects represented in the table?
So while the idea sounds nice, I think it wouldn’t work in practice. You can either have a table or a tree.
@khs, my hope is actually that it would alleviate the confusion. Currently, rows correspond to cards in the browser, but when you rightclick and, e.g., “Delete”, the note is getting deleted. The intention of this feature is to finally treat cards and notes as the different objects they are in the browser.
How do you think the UI should show the difference? And I take it that the card columns shouldn’t be enabled in the notes view then?
Add a fixed-width column (Column Name like “Group them”) in front of Qt Table (become the 1st column of the table, and “Sort Field” become the 2nd column, and so on)? And add “+” Button to It?
If the card has siblings, and it’s the First Born child (Card 1) of Note, then we add a “+” button in this column. Otherwise, we leave it blank.
Add a checkbox like “Group Cards Of Same Note”?
If more than 1 card have same note id, they share the same Notetype, Sort field, Tags, Created and Note Modified, and they can be grouped together.
Their First Born child (Card 1) is the representative of other siblings.
We can view and compare these Note property in Card View anyway, right?
We don’t have to switch to Note View to view and compare these properties, right?
If a menu operation like “Delete” has side effect that user may be misguided, we can change it to “Delete Note”?
If we want to emphasize Note property of Card, we can add a checkbox like “Highlight Note Property”, and highlight these Note Property Columns.
I see, what you propose is basically an option to show only one card per note. It’s definitely worth considering (I think there are add-ons that you let do this) but I think the mode solution is superior for the following reasons:
With two separate modes, you can have two separate headers (sets of columns, sort order, …) and switch between them depending on what you want to do.
Another advantge is that you have an actual correspondence between notes and GUI elements (rows). You can add “… Note” to all strings, but it will never be as intuitive.
Let’s say grouping is enabled and you select a card. Which cards count as selected now: just the one, all sibling cards or only those siblings that match the filter? Whichever it is, it won’t be obvious to the user.
Similarly, which card will be the parent: The sibling with the lowest index (while matching the filter) or the topmost sibling according to the sort order? Both approaches will lead to unexpected results in some cases.
But please let me know which approach you guys prefer and why.
4, Parent is the lowest index card and matching the filter.
In Note View, only Note Property is comparable and viewable, Card Property is viewable but not comparable (Or Card Property is comparable between parents, but it may lead to misunderstanding).
How about use Number of Cards (i.e. #cards) as the first column? So there is no empty and conform to your original design. The column is hyperlink and clickable.
Initially, every line in ‘Note View’ is one Note as you designed. Only Note Property Column has value. Card Property column don’t.
If current note has 2 cards, then #cards column show 2. If 1 card, then show 1. etc.
We click 2, then the Note become 2 Cards. And #cards column is filled with “-”. Card Property columns are filled with data. Click any “-”, the cards will become note again.
Sorry, it’s late in Shanghai, and I am going to sleep, good night.
That’s a great feature. I also mainly use the browser for searching and editing notes.
Arthur added such a feature into the advanced browser about two years ago and about a year ago it was moved out into a separate add-on named Card browser: List only one card per note. It would be much better to have it built-in and visible in the interface, imo.
I’m not sure if I like the current solution with the radio buttons over the table. Admittedly they match how you toggle in the preview screen so it makes sense to use them. But here’s a lot of space lost to the right and since the average user might not expect a difference between “notes” and “cards” they might not pay attention to these small-ish buttons (as they would in the preview window).
I don’t have a better solution that fits the usual UI patterns. So far I could only come up with two wide qpushbuttons that cover the whole width of the browser (as the note type and deck selector buttons cover the whole width of the add window) where the active button is highlighted. Or maybe some kind of slider (as you see them in ios/android) (but streched), as shown here (but stretched/wider and with different colors).
Apart from the question of radio buttons:
Maybe slightly adjust the background color of the table when in notes-only mode: This might indicate for the beginner that something is different and remind absent-minded people like me about the mode they’re in.
the buttons you use could have a tooltip that includes a link to the documentation about the difference between notes and cards?
Yes if you could show that a note has one-two or more cards in the UI, that would help. I’m also constantly confused, wish the naming would have been template and cards instead.
@ijgnd, I agree that the radio buttons don’t fit the available space very well. Although what bugs me the most is the wasted space rather than the empty area and that wouldn’t be alleviated by making the widget wider.
A slider wouldn’t solve that, either, but it definitely looks better than radio buttons, I’ll give that a try.
I also like the idea of indicating the mode by a different background colour. But I don’t understand how a tooltip would work. The classical tooltip that appears on mouse-over is not clickable as far as I know.
@rumo: the idea with link in the tooltip was not well-thought-out and I can’t think of a good one-sentence explanation so the whole tooltip idea should probably be ignored.
One more idea about the different background-color: I guess the card mode would remain the default. So the note mode as the exception would get the alternate background color in the table. Maybe once the note button is activated/clicked its background color could be changed to the same color as in the table. This could give you a visual hint that the table state is related to the note button?
About the “wasted space”. If we already add another row for the notes/cards button we can as well fill it with other stuff. Maybe more buttons?
Since .41 removed the buttons for filter, search, preview from the search row a row just with buttons might be useful? In general @AnKingMed advocates for the inclusion of the fastbar add-on and I guess he gets lots of feedback from ios users. Maybe a button could be shown that allow to toggle the full fastbar (which was built-into 1.x).
More table related but less popular maybe a function from my Table/Editor side-by-side (horizontal split) or even less popular a function from my Browser Maximize/Hide Table/Editor and I guess there other ideas out there. To be clear I’m not advocating to include anything from my add-ons - from a maintenance perspective I prefer minimal changes to the browser. These were just the first ideas that came to my mind: for me a toggle that decides what’s shown in the table feels pretty close to buttons related to the position or size of the table which for me is related to toggling UI Elements in general. I don’t know how useful these would for a wider audience.
Figuring out how to best fill the new row and convincing Damien of such a big change might mean we never get it. So maybe a new row can be avoided altogether? Since .41 removed the buttons for filter, search, preview from the search row maybe now there’s enough space to move the radio buttons (or a slider) to the same row as the search bar?
You are right, there are a lot of things that can go next to the slider, so we probably shouldn’t worry to much about the empty space. Even if it’s not filled in vanilla Anki, add-on authors may appreciate it.
Putting the slider next to the search bar would be economical, but I have deliberately avoided it: On the one hand, it would shorten the search bar. On the other hand, it should be positioned closer to the table than to anything else to emphasise the immediate relationship.
