standardnotes / forum

Support from other community members. For 1-on-1 help, please contact help@standardnotes.com.
https://forum.standardnotes.org
196 stars 9 forks source link

Multiple open/active notes? #958

Closed 17prime closed 1 year ago

17prime commented 4 years ago

Is it possible (or will it be) for notes to open at the last working/viewed/edited/active position? Or for having multiple notes remaining "active/open" while switching among them?

I mean, one thing I like about a simple folder of md files for notes: When I'm working on something I can have several different notes/files/tabs open in an editor at various positions to refer to and jump between them without losing my place in any of them. Switching between notes in SN always reopens them at the top of the note meaning I have to scroll to whatever info I was just looking at a minute ago. This behaviour makes the SN clients less useful for active reference use while working on a project.

Currently, I can get around this limitation by using the standardnotes-fs tool to mount my SN account as a filesytem and use an editor to open the mounted folder and then have several "notes" open at once, but it would nice if the actual SN apps could operate in a similar manner.

moughxyz commented 4 years ago

Multiple notes open at a time is part of our design specs for v4. But v4 hasn't started development yet. So most likely nothing here in the short term. But definitely something we're thinking about.

bschlagel commented 4 years ago

As a short term solution: I would be SO happy to at the very least have saved per-note scroll position, even just in the plain editor to start.

(This part of the request is already discussed here: https://github.com/standardnotes/forum/issues/276 — but I think worth noting that even partial support would be a huge help; this is currently one of the most glaring UX shortcomings of the app)

17prime commented 4 years ago

As a short term solution: I would be SO happy to at the very least have saved per-note scroll position, even just in the plain editor to start.

(This part of the request is already discussed here: #276 — but I think worth noting that even partial support would be a huge help; this is currently one of the most glaring UX shortcomings of the app)

Indeed, it is a rather large shortcoming --- and if it would be "somewhat trivial" to do for the plain editor (as stated in 276), then why not at least address it for that editor and perhaps others could then add/implement similar functionality in other editors (like the indent editor)?

moughxyz commented 4 years ago

You'd be surprised. Users say they'd be ok with the feature in just one editor, but when you do that, they'll complain about "inconsistencies" with other editors. You may be a different breed of users, but this is what I've seen. In any case, I hear ya. The feature is nonetheless not totally trivial because scroll position depends on window size, screen resolution, panel width, etc. You might say, "even an inaccurate scroll position is better than none," but again, what users say before and after a feature is implemented is totally disconnected.

bschlagel commented 4 years ago

Thanks for the reply @mobitar! Totally understand it's a challenge.

More general comment, having observed this project for a while now, I do get the impression that supporting multiple third party editors is tying your hands in a major way when it comes to implementing certain features that seem like table stakes v1 features in other note / text editor apps. I for one would be happy to see far fewer editors, if it meant things being able to be more polished / cohesive overall. I'm a paid user and big fan of the product, but this is one thing that concerns me, that the somewhat chaotic editor landscape is holding back certain things that might otherwise be straightforward feature development.

To your point above: I think I have a pretty high level of attention to detail, and if it felt like all the editors were on equal footing to start with, I might be annoyed about a lack of feature parity. The thing for me is: there are already so many inconsistencies with the other editors — to the point that I don't even use them in the first place! My current feeling is that "plain editor" is the only one that feels nice to use (things like scroll position notwithstanding) and most of the other editors are varying degrees of "feels like I just switched to running an editor emulator on an entirely different operating system" or something. For example I would vastly prefer one really solid native-feeling markdown editor with full keyboard shortcuts, proper scroll position memory, etc. to four markdown editors that all feel janky in different ways.

moughxyz commented 4 years ago

I would vastly prefer one really solid native-feeling markdown editor with full keyboard shortcuts, proper scroll position memory, etc. to four markdown editors

Me too :) But we're really not an editor building company (yet). I think it takes a team of its own to build an editor. So we had to go with diversity of choice rather than selecting just one open-source editor and being at the mercy of that project's contributors.

I still think editors are a great experience on the web/desktop, but may perhaps feel emulator-ish on mobile. This is because they're largely over-powered and not designed with a mobile-first mindset.

In any case, we're making big improvements here with v4. @zsoltszilvai could potentially elaborate if he wants :)

I think editors will always have a place in SN because without them, we couldn't get things like TokenVault, which users really love, and spreadsheets.

17prime commented 4 years ago

You'd be surprised. Users say they'd be ok with the feature in just one editor, but when you do that, they'll complain about "inconsistencies" with other editors.

I get your point --- and probably all the moreso because it would be functionality implemented in the "free" product that doesn't extend across the paid editors (although, in terms of inconsistency, there is already plenty of that amongst the various markdown editors).

I agree with pretty much everything @bschlagel says. Without positional memory when switching between notes, SN feels more of a casual note store for info you'd use to store and look-up/retrieve a piece at a time, rather than a place to store and actively use reference/project notes/materials.

I am not a paid user, still on the fence, if only because I have to use a third-party tool (that isn't rigorously tested) and external editor to achieve basic functionality --- and because it is hard to see how you will make a path forward in base functionality when your monetized path includes various editors (with various architectures) that are outside your development purview (sorry if it sounds harsh, but it doesn't seem to reconcile well with your longevity statement). Is there any (even wild guess) timeline for V4?

davidlee321 commented 4 years ago

Agree with the reasons some users have raised for this feature.

I wonder if allowing multiple instances of the app be open could be an easier way to achieve this (at least in the meantime) than say trying to implement tabs.

zsoltszilvai commented 4 years ago

First of all, thank you all for your feedback. I really appreciate you taking the time to tell us how you use Standard Notes and what problems you face. This thread is definitely providing us with some great ideas and insights.

I've been gathering feedback from both existing and potential users for a couple of months now and learned so much about what people do and don't love about Standard Notes. Having third-party editors do come with certain limitations but they also enable many of our users to do so much more.

Personal experience: Designing with these constraints can be challenging but they often force us to come up with more efficient ways of solving problems.

With this being said, you're not alone with the above-mentioned problems. And as Mo mentioned, we've been exploring different potential solutions for them.

As for the timeline, we've already been working on v4 for some time (doing research and design work) but haven't started implementing it yet. I'd like to believe that we're not too far away from getting started but can't say anything specific. Maybe @mobitar can share a bit more on this.

In any way, thank you for your feedback and please keep it coming:)

apederson94 commented 3 years ago

+1 for multiple tabs. Can't wait for v4!

bmhj2 commented 3 years ago

Not sure how far along things have come since the last post in this thread was added but just to say I'd also very much welcome some kind of tabbed view or capacity to display a window with a second instance of the app. I've been using it for some time and have found it very impressive and useful but the lack of being able to keep different windows open for different workflows is a real shortcoming in comparison with other apps.

Parkertg commented 3 years ago

As an alternative way to get a similar result.. could one launch another instance of SN? You can of course launch multiple via a browser. but not multiple of the app. Anyhow, that'd be how I've done it thus far. Any reason we can't open multiple of the app? (windows user here)

EDIT: oops.. in 1 of the 2 comments I skipped. I see my idea was already mentioned..

moughxyz commented 3 years ago

I believe only one process can access the local database at a time, so multiple desktop application sessions wouldn't work.

virtuallyvlad commented 3 years ago

SN gets a request for multiple notes and preserving note states pretty much every year :)

Multiple notes/windows/instances/tabs: https://github.com/standardnotes/forum/issues/183 https://github.com/standardnotes/forum/issues/485 https://github.com/standardnotes/forum/issues/502 https://github.com/standardnotes/forum/issues/627 https://github.com/standardnotes/forum/issues/677 https://github.com/standardnotes/forum/issues/958 https://github.com/standardnotes/desktop/issues/298

Preserving note states (scroll position, selected text): https://github.com/standardnotes/forum/issues/276 https://github.com/standardnotes/forum/issues/768 https://github.com/standardnotes/forum/issues/509 https://github.com/standardnotes/forum/issues/940 https://github.com/standardnotes/forum/issues/958 https://github.com/standardnotes/desktop/issues/295