First sketches for a PineNote UI

[1jss]

When the PineNote was announced I immediately started dreaming of what a UI could look like.

In my understanding the use case of the PineNote is so different from the PinePhone that the current GUI initiatives for mobile aren't applicable even if they could be made to work with the hardware. Instead I think the main focus should be reducing input latency as much as humanly possible. One way to do this is to not use gray scale as it (as I've understood it) requires multiple screen updates. Watching similar proprietary products flicker their way through the UI is not what I wish for this device. One alternative to grayscale is using dithering, and I think the screen has enough resolution to make this look good.

To give an example of what this could look like I sketched together two mockups of what a home screen and a note app could look like. They are both in the right resolution and uses only black and white. I've here used the Floyd–Steinberg dithering algorithm.

[barray]

Awesome designs. I thought it would only be a matter of time before somebody suggests we write a new UI The first screen (to me) looks very much like what already exists for mobile UIs and the second screen I would imagine to be an application (that might not even be eink exclusive).

Given how long it took to create a PinePhone UI that works - I would suggest to build upon this progress to avoid duplicated efforts and more delays. I imagine a *large* number of PinePhone apps would also work really well on the PineNote without any real changes at all.

I imagine this could be achieved with an intelligent display driver that updates the display only when required and applies some post-process filtering to make icons, etc, more e-ink friendly. As I understand it, the eink display is pretty capable and it might even be able to play video at 30 fps.

Also, I would suggest that in general, high contrast icons would benefit all projects anyway. Don't forget that a significant amount of the world is colour blind.

[1jss]

Awesome designs. I thought it would only be a matter of time before somebody suggests we write a new UI The first screen (to me) looks very much like what already exists for mobile UIs and the second screen I would imagine to be an application (that might not even be eink exclusive).

Given how long it took to create a PinePhone UI that works - I would suggest to build upon this progress to avoid duplicated efforts and more delays. I imagine a *large* number of PinePhone apps would also work really well on the PineNote without any real changes at all.

I imagine this could be achieved with an intelligent display driver that updates the display only when required and applies some post-process filtering to make icons, etc, more e-ink friendly. As I understand it, the eink display is pretty capable and it might even be able to play video at 30 fps.

Also, I would suggest that in general, high contrast icons would benefit all projects anyway. Don't forget that a significant amount of the world is colour blind.

Thanks.  You're right, the second screen is a mockup of a notes application.

You are also right that the launcher looks just like a smartphone launcher, but in my head this device is very different to a smartphone. I agree that it would be great to use as much of the existing tech (and apps) as possible, but "just" applying the current os would not give us a great E-ink device. It would be a flickering grayscale PineTab. That might be what some envision, but to me the real selling point with e-ink + pen input is that it is close to instant. To achieve that feeling reMarkable writes directly to the frame buffer. Correct me if I'm wrong, but I don't believe that the current PinePhone stack (with low contrast and UI animations) + post-process filtering would give us that.

[barray]

To achieve that feeling reMarkable writes directly to the frame buffer. Correct me if I'm wrong, but I don't believe that the current PinePhone stack (with low contrast and UI animations) + post-process filtering would give us that.

I believe there is nothing stopping you from writing straight to the frame buffer in any case. I believe vlc can do this for example. xserver and wayland are just glorified frame buffer wrappers after all.

But given the PineNote has so much processing power, it may end up being not a bottleneck anyway.

[1jss]

I've now started coding a mockup based on the home screen design above.

NoteLauncher on GitHub

Please join in if you're interested!

Current state:

(Click for high resolution)

[barray]

I've now started coding a mockup based on the home screen design above.

NoteLauncher on GitHub

Please join in if you're interested!

Current state:

(Click for high resolution)

Very nice! Would you mind adding a license to the repo - I would very much be interested in using the icons for another Pine related project.

[1jss]

Very nice! Would you mind adding a license to the repo - I would very much be interested in using the icons for another Pine related project.

Will do.
Haven't thought through what I want to do with the licensing of the code yet.
I might release just the icons as a separate repo instead.