greenheart / lifewheel Goto Github PK

Maybe integrate with https://syncedstore.org/docs/ or https://github.com/yjs/yjs

The benefit would be to standardise the underlying data structure.

Potential drawback is that we dont need the collaborative features right now. And this might add additional app code size without adding much value.

This will be especially nice if we use horizintal scroll/swipe to navigate. Will create a nice app UX.

This could be used for the graph and the grid, to always scroll/swipe to the start+end of columns

For users who want convenience, it should be possible to save crypto keys in their browser so they can be reused later. This will improve convenience at the expense of security, but should fit well with the app threat model (assuming that your device is secure).

It should be possible to opt-out for those who only wish to keep their crypto keys in memory during app usage, but never save to persistent browser storage.

This might give some input to start exploring solutions: https://pomcor.com/2017/06/02/keys-in-browser/

Maybe a short breathing exercise, to be fully present.

This could have a breathing animation, with a circle that is growing and shrinking. Continuing for something like 10 deep breaths. 10 breaths * (2 sec in + 2 sec out) = 40 sec grounding exercise. With a button to skip. Then you automatically navigate into the lifewheel reflection.

• secure passphrase generator
• enter custom passphrase
• encrypt
• decrypt

Annoying bug but simple fix to sort the arrat of combined reflections before showing them in the app.

https://github.com/gibbu/svoast

For example when decrypting a link, or loading an unencrypted link.

If the page is has vertical overflow (y), the browser scrolls the page in addition to just changing the slider value.

Should be fixable by ensuring the page always fits vertically. Adjust spacing.

Potential solution: bevacqua/dragula#487 (comment)

Read this report and see if and how we can use the insights in lifewheel.

Very important to consider that this is overly focused on individual actions - which needs to be complemented with collective actions to create better structural and material conditions for wellbeing for all within the means of the planet. Thus power analysis needs to be a part of wellbeing advocacy, since people have very different circumstances due to inequality and other injustices. Thus we need both a individual and collective approach, and ideally could mention both when talking about the lifewheel.

https://neweconomics.org/2008/10/five-ways-to-wellbeing

• Connect
• Be active
• Take notice
• Keep learning
• Give

Ideally, this could be included in the descriptions of each dimension. Also make sure it is empowering rather than judgmental. Instead of "Have you been physically active?" it could be phrased as "Consider being physically active for increased wellbeing".

• Show dots stacked vertically for each dimension. These represent a reflection entry that was made at a specific date. They are either spaced by date, or with equal width and spacing to make it easier to develop and more consistent, and most importantly not making people feel bad if they didn't check in for a long time. As long as we clearly show the date of the highlighted entry, it will be fine.
• Show lines for each dimension (with the respective colour), connecting the dots for each reflection entry.
• Show icons to clearly symbolise what the dimensions mean.
• Allow scrolling (swiping) left and right to navigate in time. Use scroll snapping to highlight something in the middle (and also show that reflection in the big life wheel). If there was a comment added for that reflection entry, show it somehow (ideally directly if you scroll), so you can read it together with the big life wheel.
• clicking (tapping) anywhere in the column of dots will change focus to that reflection entry, and move it to the centre (maybe even at the beginning and end we could add )
• Maybe add a filter button to open a pop-up/modal to configure which dimensions you want to include in the graph. For example if it's crowded with everything selected, maybe you just want to focus on a few variables.
  • Alternatively, perhaps you could hover/tap a dimension (in a column that is a vertical stack of dimension icons positioned sticky to the left of the timeline, at the edge of the screen) to toggle the line on/off for that dimension.
    • For hovering/tapping, it could bring that line to the front, so it's visible on top of other dimension lines and dots that might have the same value (7 for example).

https://github.com/vite-pwa/sveltekit

Check this out https://love2dev.com/pwa/ios/

This will simplify the app

Use the new FS access API where available and fallback to legacy solution where needed.

https://github.com/GoogleChromeLabs/browser-fs-access

https://layercake.graphics/

First, test if https://github.com/nodeca/pako can compress data more efficiently than we can do ourselves. Also experiment with various strategies, maybe specifying a dictionary and finally try enabling/disabling the header to use the raw mode which uses slightly less data.

Or maybe we should use a custom solution

Maybe we get better results with a custom solution.

The biggest advantage is that we don't need any external dependency, and the solution will keep working in the future.

However, this is likely more work and will require manual updates if we change the shape of the data.

The binary data used to encode links currently use one byte even for small numbers. This is quite inefficient.

Take for example the LifewheelState which is represented by 8 numbers between 1 to 10.

Since we currently only need to store 10 distinct values for each position in the LifewheelState, we need 4 bits to represent 10 as binary (1010).

Since we only need 4 bits to represent each value, this means we can compress the data without any data loss by storing two values in the same byte (8 bits). Especially for links, this will save important characters, which ultimately helps keeping the links a bit shorter.

Proposed solution

Store

Code use for experiment:

function dec2bin(dec) {
  return (dec >>> 0).toString(2);
}

function bin2dec(bin) {
  return parseInt(bin, 2)
}

dec2bin(10) // returns '1010'
bin2dec('1010') // returns 10

• Idea: Use CSS trigonometric functions sin() and cos() to position the icons evenly around the circle. Maybe use a offset to center icons within each dimension.

There is a WIP branch that could be a good starting point: https://github.com/Greenheart/lifewheel/tree/feature/position-icons-circle.

Inspiration: https://codepen.io/kevinpowell/pen/qBMQJVr?editors=1100

We could use the base CSS for each circle, and then provide the CSS variables as svelte props in an each block. This way we don't need Sass.

This is a much better UX to make it clear which was the latest imported reflection.

Move technical details further down, and keep the intro more interesting to people using the app.

Show how things have shifted throughout a given period. This would be really nice to combine with a lime chart that gets drawn bit by bit. This data would tell a story. Also allow pausing/resuming at any given moment with a button or spacebar.

Thanks @christiangebel for the idea!

This would be useful to build similar apps in the future.

• Basic persistence with localStorage. Add storage keys as constants.
• Auto sync app state with localStorage whenever there are changes.
• If the current file is encrypted, require password prompt to see the data whenever the app reloads. Or maybe for convenience, let the key be stored in sessionStorage to quickly decrypt the data.
  • This means data in localStorage needs to be encrypted by default, and only stored in plain format if encryption has been disabled.
  • However, it might be more convenient to keep localStorage state unencrypted, to allow quick app starts. This is probably what the majority of people want, and then we could optionally enable local encryption to turn the app into a private, personal diary that only you can open.
  • If we store local data unencrypted in localStorage, it assumes you want to save data in that browser. If you don't trust the device, then clear browsing data for the app - or use a private browser tab. This gives a good trade-off between security and convenience.

Future related tasks

• Encourage people using the app to export data to a link or file.
• Add confirmation dialog before clearing local data
• Add confirmation dialog before opening file (and overwriting the local data). Or even better, automatically combine all imported data. And let users delete specific entries if they want to, and then re-export new link or file.
• Add tab sync insired by https://github.com/excalidraw/excalidraw/blob/0726911fa608d1c1ad9480badbafa61f2acd8b9c/src/excalidraw-app/data/tabSync.ts. Probably needs to load whenever the app regains focus.
  • Maybe listen to the storage event to check if the data was updated in another tab https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event
  • maybe implement using https://github.com/joshnuss/svelte-local-storage-store instead

Potential benefits

• Adds possibility to store binary data without a step for parsing/stringifying data. This could improve performance.
• Might make it quicker to update and delete reflection entries in the middle of the app state.
• By making it possible to store binary data, it would be possible to encrypt data at rest, and require password prompt when starting the app. Might be good to improve security, since we have to assume local data on the device (like localStorage or even IndexedDB) can be read by other apps on the device. With localStorage it's also possible to encrypt data at rest, but it's primarily with IDG that this will give better opportunities to store any binary data.

Reasons against

• Slightly more complex implementation to understand and maintain.
• More code needed in the client bundle.
• Might not be worth it for our simple app.

Ways forward

If we want to explore this further, here are some potential wrappers around the IndexedDB API to wrap common operations in Promises:

• https://www.npmjs.com/package/idb
• If we only need key: value storage: https://www.npmjs.com/package/idb-keyval

Using the new dynamic viewport units could make this easier than in the past https://web.dev/viewport-units/

Maybe try https://www.skeleton.dev/components/app-shell along with other UI components from there

Instead, recommend people to use a save file instead.

The limit could likely be tested by creating as many fake entries as possible. A bisect method would be useful, starting with an extremely high amount of reflections to find where it doesn't work. Then decreasing to an amount where it does work, and go up again from there.

Edit: this will also need to apply for the QR code. For larger datasets, only allow file export and import.

• why to use the app
• how to use the app
• key features and how to get the most out of them.
• title and one sentence plus image for each section (3-4 in total). Screenshots of the app.
• this landing page can be opened with an info button in the menu/ corner of the screen.
• the landing page is visible when there are no previous reflection entries. Then we show those instead of the landing page when people have begun using the app.

• From a UX perspective, this feature could add much more depth and value to each reflection. It would also make it more fun to look back on historical reflections, and understand what happened at that point in life. Why did you feel a certain way? What do you want to focus on in the coming week?

Implementation

• Implementing this would require a new protocol version, since the data format changes.
• We would also need to update the encoding to handle variable length data. Either write a custom implementation, or look into other solutions for this. Should be doable, since we know the length of each variable length field, and could encode that as an int32 (2 M characters) or int16 (32 k characters), depending on what should be the max length of the text entered by the user.

implementation ideas

• maybe use https://github.com/dmonad/lib0 and the module lib0/encoding for variabler lengrh encoding.