2

I'm working on a note taking app. One of the feature is that you can group the notes in a folder like manner in which one can create. subgroups inside groups and more subgroups and put notes/notebooks inside it. The app has also a feature where the user can make notebooks in which the user can add notes (You cannot put a notebook inside a notebook). But doesn't that make the notebook same as a group without subgroups? How useful this feature can be? Can having both confuse people? Thank You.

Edit:

It already has hashtagging so one can link notes regardless of grouping. The smallest unit is called a "note" (there are different kinds of notes). Currently, you can put a note inside a "notebook" and/or a group. There is nothing beyond "notebooks" but groups. The question here is if I should call a group of notes "notebook" when the user could just group the notes without the whole notebook thing. A bunch of note taking apps lets you group the notes into groups/folders and/or notebooks and I've always found it confusing. But I doubt if there is an actual point in being able to do this.

  • I think you answered your own question in the Edit. If a group of notes is the same as a notebook, why call them different names? Different names might imply they behave differently, which they don't. Therefore, labeling them differently will needlessly confuse users. – Nicolas Hung Jun 10 at 15:54
  • I was just confused because other similiar apps do this and I thought there was some point I was not aware of. – x0_0x Jun 10 at 16:41
  • I'm just gonna stick with groups only, no notebooks. – x0_0x Jun 10 at 16:42
1

I would test the concept with some users first, however I do think having both might be confusing. What is the difference between a notebook and a group? Aren't both simply groups of notes? If they are, why differentiate them? I would advise choosing one and sticking to it.

An alternative way to organize notes can be using hashtags, so users can both group them but also have an opportunity to link and classify them regardless of their groups.

1

TL;DR: Functionally, there should be little-or-no difference between top-level containers1 ("groups") and lower-level ones. However, it may be useful to allow users to give semantic labels2 to different containers, and – ultimately – to use those labels to affect how the UI displays containers and their contents.


I think part of the problem is that notebook can be used in two similar – but to my mind distinct – ways. One potential use is as part of the functional description of how your program should behave; the other use is to do with the semantic2 meanings a user may assign to different levels of information.

  • Functionally, your program should3 be able to arrange notes, and collections of notes in hierarchies of the user's choosing (together with #hashtaging for linking without regard to the hierarchy).

    Above, I said "one potential use [of notebook] is as part of the functional description". The reason for the qualification is that – at a functional level – there essentially are only two "things": containers1 and notes. Notes are the "leaf nodes" of the hierarchy (where information is stored); containers make up the rest of the hierarchy and can hold both containers and notes.

    As you rightly suggest, having a "different type of thing" for top-level containers (with a different name, e.g. notebook) is almost certainly the wrong thing to do™. There should be little-or-no difference between a container at the top-level of the hierarchy and one that's seven levels deep. Any container, whether at the top level or not, could be moved into another container, and any container (within an existing container) could be promoted to the top level.

  • Semantically, though, I think things are different. A user may find it useful to "categorise" containers at different levels of the hierarchy. As such, they could (should?) be given the option of both labeling certain types of containers4, as well as naming specific instances of a container. For example:

    • In a physical filing systems, documents (=notes) may be organised into folders5, wallets or pockets; these in turn may be held inside suspension files, lever-arch files or box-files. Suspension files may be stored in filing cabinets.

    • A large document (whether physical or electronic) may be organised into chapters, sections, sub-sections etc.

    • You might collect a number of thematically-similar documents together to form a volume, a workbook or a notebook.

    • You might gather a collection of notebooks onto a bookshelf.


    Such groupings, especially for an evolving collection of knowledge (as a user might attempt to capture in a note-taking application) will tend to change over time. A user might initially create a notebook called "User Experience", in which there are just a small number of individual notes on various aspects of UX (usability, accessibility, responsive design etc.). As the body of knowledge grows, notes may be grouped into their own sections. As sections grow, they may be "broken out" into individual top-level notebooks. If the collection of "notebooks about UX" starts to get lost among other notebooks, you might move them all to a new top-level container(labelled bookshelf), called "Books on UX".

It probably goes without saying that containers, at any level of the hierarchy, should have a user-specified name/title. Whether you also allow containers to "have a type", and exactly what "having a type" means, depends on how complicated you want to get:

  • The "type" could just be a semantic label that a user can apply to a container to help them better understand the hierarchy of information. Functionally, a "notebook" would behave no differently than a "bookshelf" or a "chapter", but consistent use by the user of the different types may allow them to navigate more easily.

    • This option would have almost zero overhead, other than storing a "type" against each container.
    • While there may be predefined types, user could freely add their own type-names.
    • You probably don't need to worry if a user chooses to have a container they've labelled "bookshelf", inside a something they've labelled "chapter", inside a "book".
  • The type could be used as part of an enhanced user-interface: certain container types (e.g. bookshelf, (note)book) could be displayed as such. Functionally, there would still be no essential difference, but the enhanced UI would emphasise the semantic differences.

    • There would be a much larger overhead to implement the enhanced UI.
    • Users could still be allowed to add their own type-names, but only predefined ones could be displayed differently.
    • You may want to store extra "meta-data" against certain container-types. Books might have a colour setting, and/or a front-cover image; bookshelves might have colour or "style" settings.
    • You would have to decide whether to allow "silly" nesting or not (e.g. a "bookshelf" being moved inside a "book"). I'd probably allow it (the user may be about to change the container-type), but you would need to make sure the UI doesn't do "odd" things if they do.

Of course, all this may be too much if you're aiming for a simple note-taking app. If so, decide on a single name for your containers and stick with it. "Group" or "folder" are probably as good as it gets.


1 I'll be using containers for "the things that can contain other things". Obviously this pretty much corresponds with your term groups, but – I hope – reduces any functional/semantic blurring that "groups" might carry.

2 I'm not 100% sure semantics is the right term. As (hopefully) can be seen from the main text, I'm using it to cover the potential user-assigned meanings to different levels of the "information hierarchy". If there is a better term for this, I'll happily edit it in.

3 I'm taking it more-or-less "as read" that there should be a hierarchical structure. While it is not the only way of arranging information, the fact that hierarchies are so ubiquitous in both computer and manual filing systems is a strong argument for such a system within your note-taking application.

4 Here, "types of container" is purely semantic. At a functional level, all containers are the same; at the semantic level, some of those functional containers will be "acting as" a notebook, some will be acting as a document, some as chapters etc.

5 All links are for illustrative purposes only: I have no affiliation with, nor do I endorse, any specific product or Amazon.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.