I think it’s clear we want an offline-mode but we have different uses cases under that same label. So far we have identified:
offline mode as in “desktop app”. This is typically a solo-user use case where you want a “native app” experience the likes of other tools like The GIMP or Inkscape. This requires encapsulating Penpot using some technology like Electron.
Offline mode as in “unreliable internet connection protected mode”: This could use Service workers or anything similar in different browsers to keep an async consistent state. This would mostly benefit solo-user scenarios since real-time collaboration feature within Penpot could easily lead to destructive actions. You could be on a plane or just having intermittent network issues while other users keep updating that same artboard so how is Penpot going to manage a “visual merge” of all that?
Offline mode as in “no third party tools are involved”. This is more to with integrations and the role that some third party plugin could play. This is fine with solo-user and multiple users collaborating. I would call this “incognito mode Penpot”.
I think you’re referring to scenario #2 here and I believe this is the trickiest of all due to inherent collaborative nature of Penpot. Actually, Penpot can handle some intermittent network issues already but I wouldn’t be comfortable if those go too far in time.
Is your use case compatible with approach #1? That is, a non-networked deployment of Penpot that runs locally in your laptop? Or would you absolutely need to share such Penpot instance AND have this offline-mode? Could you please elaborate a bit more your use case? THANK YOU!
As a solo-user, my perspective was initially limited to approach #2 where I could use Penpot while travelling with a Chromebook, but after reading through your comment I’ve done a bit more digging around to broaden the discussion.
With approach #1, given the plan is to develop a desktop application:
having a desktop app certainly makes Penpot more accessible and easier to work with
are there plans to expand this further i.e. iPad app with support for the Apple Pencil and similar devices. I think this would have to go beyond Electron, if you’re targeting iPadOS / Android - considering building for Android allows users on Chromebooks to “install” Penpot as an App (alleviating my issue).
(related; on a tangent) how about mobile applications, i.e. Figma has a mobile app limited functionality for “previewing”, I’d love for Penpot to have something similar
As long as I’m able to create, edit, view (pre-dowloaded) penpot prototypes offline / on the go, and then share these either to a self hosted or the cloud instance, I’d be more than happy with approach #1.
Understandably, approach number #2 would affect collaboration features, a workaround however could be something as simple as creating a copy of the original project, and in case there are no new changes to the original file, replace it else show the differences (a bit like branch diff with git) and allow the user to resolve any conflicts, this is long winded, but in scenarios where “downloading an app” is just not possible, Penpot would just work seamlessly - given that the user’s browser has cached the service.
I had not considered approach #3 perviously, but now that you mention it my understanding is this is targeted towards enterprise use cases where firewalls / company policies play a huge role.
I’d be happy with approach #1 or #2 or perhaps both personally, as long as the “net is cast as wide as possible” i.e. covering as many scearios and devices as possible, this issue can be mitigated.
We all recognize that this is not an easy problem to solve. To some extent, I think you have to pass the responsibility to not do harm to users. Here’s a few approaches that might work.
Allow collaboration to be turned off to avoid any problems … but what if they open it across sessions ?
Allow a file to be “locked” to one session … but how do you elegantly “acquire” the lock from an inactive user?
Notify connected users when another user may be editing offline and let them decide if they should proceed … but what about when the off-liner reconnects?
I’ve actually used all three of these solutions in different B2B scenarios and they all have their own risks. But users were grateful to have the online option and in fact it was critical in some markets.
Personally, I liked using #3 the most. When the disconnected user showed up with conflicting changes, we just created a timestamped version and placed a notification in the source file that could be dismissed by the next user there. Evernote has used a similar solution for a long time as well. It’s not perfect, but the trade-off is worth it to give the user control.