Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beta Feedback #15

Open
NoelDeMartin opened this issue Jul 15, 2024 · 8 comments
Open

Beta Feedback #15

NoelDeMartin opened this issue Jul 15, 2024 · 8 comments

Comments

@NoelDeMartin
Copy link
Owner

Some days ago, I deployed a development build of the next version to focus.noeldemartin.com. Please, give it a try!

As I say in the page, though, this is a beta. So beware of using it in production. Here's the parts I consider mostly done:

  • Features: It's very unlikely that I add any more features at this point, but if you think something super essential is missing, let me know.
  • UI: I still have to tweak a couple of things, but overall this is what the app will look like.
  • Syncing/Log in experience: I still have to improve it, but if something is broken please let me know.
  • Data schema: The current schema is not set in stone, but if I don't find a compelling reason to change it; this is what it'll be upon release.

And here's some things that I already have in the roadmap, and will tackle before the release:

  • Data migration: Users of the legacy version of the app should be able to start using the new one with the same data. This will probably involve a migration to the new format, rather than supporting both schemas.
  • A11y review: I already kept accessibility in mind during development, but I have to do a final pass before releasing.
  • Animations: I know some animations are botched. Even though the UI is mostly done, I still have to clean up some of the animations.
  • Container choice: In the same way that I do with Umai, I intend to allow advanced users to specify which container they want to use for storage. Something that won't change, however, is that a container will be used for each workspace, and each child container will be treated as a list in the UI. I won't support nested nor sibling containers for lists.
  • Performance: I haven't tried using the app with a lot of data yet. But I myself have many tasks in the legacy version, so I'll make sure to stress-test it before releasing.

And that's it! If you have some feedback, please leave me know in this issue or contact me in private. If you only care about the final release, you can subscribe to this issue and I'll close it when the beta is over.

Thanks!

@Vinnl
Copy link

Vinnl commented Jul 15, 2024

The new UI is image

As for the data model, I must say I was slightly surprised to see a new main Container created in my Pod, which seems like a fairly generic name for a fairly specific task. I imagine if all apps are going to put all actions I do in them in there, they're going to slow to a crawl. But in practice, with Solid's current popularity, that won't be a problem 😅

Since you mentioned a11y review, I also noticed that there's no close button on the settings/account dialog, and you can't close it with Esc.

But nice job!

@NoelDeMartin
Copy link
Owner Author

Hey @Vinnl, thanks for your feedback, as always :D.

As for the data model, I must say I was slightly surprised to see a new main Container created in my Pod, which seems like a fairly generic name for a fairly specific task.

Yeah, this is part of what I want to improve when I say "Container choice". Besides letting people choose, I also want to think about better defaults. Initially, I thought it'd be fine to have containers in the root because I don't think people is going to have many workspaces (though who knows). But now, I'm leaning more towards putting everything inside /tasks/ by default.

The real problem, though, is how to call the default workspace 😅. The idea is that you would have one workspace for each part of your life (Work, Household, Hobbies, etc.), and in the previous version of the app I explicitly ask users to name their workspaces. But here, I wanted to remove friction so the initial workspace is created automatically (you can rename it later). And the name I'm using for this default workspace is "Main", which I probably took from git's default branch name nowadays. But I'm not super happy with that choice :/. So I'm all ears for suggestions, because so far I haven't been able to come up with something better. I guess I'll also do some research to see what other apps do.

Since you mentioned a11y review, I also noticed that there's no close button on the settings/account dialog, and you can't close it with Esc.

Thanks for mentioning that. I'm actually using Headless UI, so Esc should be closing the modals. But I guess I broke it somewhere, I'll look into it.

In my other apps, I have close buttons in modals. But here, I wanted to remove as much clutter from the UI as possible, in line with the "focus" theme. I even pondered having a "focus mode", but in the end I think the default UI is pretty minimal already :D. Though maybe I overdid it a bit 😅. I'll reconsider adding the close buttons, even after fixing the Esc interaction.

@Vinnl
Copy link

Vinnl commented Jul 15, 2024

I think main is fine, if it's clear that it's scoped to tasks - so /tasks/main/ (and /tasks/work/, /tasks/household/, etc). would definitely be A-OK!

@aleksrutins
Copy link

aleksrutins commented Sep 22, 2024

I'm finding that it occasionally duplicates all my lists (without duplicating their contents) when synchronizing.

Edit: For one workspace, it's now duplicating the contents of the lists without duplicating the lists themselves.

@NoelDeMartin
Copy link
Owner Author

I'm finding that it occasionally duplicates all my lists (without duplicating their contents) when synchronizing.

Thanks for reporting this, I've also seen it myself sometimes; and others have mentioned that it also happens in Umai 😱.

The problem, though, is that I haven't been able to reproduce it in my development environment :(. I suspect it has something to do with race conditions. I'll definitely look into it more in depth before the final release, but if anyone finds a way to reliable reproduce this, please let me know.

@angelo-v
Copy link

I have managed to reproduce the sync duplication in Focus with a fresh pod on localhost and only using one browser:

  1. Create a List
  2. Add a task to the list
  3. Rename the list

The renaming somehow leads to all tasks in the list to be duplicated. It just adds the same task file with an additional suffix to the container (similar I have seen with recipes in Umai)

image

Network wise it GETs the container, then GETs the task that is in there, and then it tries to GET the task file with the suffix for some reason, fails with 404 and then makes a PATCH to create it.

I exported the HAR file (zipped for github upload), you can import it to you browsers network tools for further analysis:

focus.noeldemartin.com.zip

image

This is reproducably duplicating tasks, whenever I rename the list.

Notably the renaming does not change the name of the list in my pod, it just duplicates the tasks

@angelo-v
Copy link

Just noticed on my test pod it also started to duplicate type index for some reason (never had that in my real pod luckily)

image

Here is another network recording that lead to this:

type-index.zip

For some reason the app seems to decide it needs to create another type index, although the original type index could clearly be fetched.

It just randomly adds a new type index to the profile and then creates the file

INSERT DATA {
            <http://localhost:3000/focus/profile/card#me> <http://www.w3.org/ns/solid/terms#privateTypeIndex> <http://localhost:3000/focus/settings/privateTypeIndex-ee89884d-bf78-4965-a130-8d26c1b67d7b> .
        }

@NoelDeMartin
Copy link
Owner Author

That's awesome @angelo-v, thanks a lot 🙇. I was able to reproduce this in a test, so I'm sure I'll be able to pinpoint the issue now :D. I still haven't been able to reproduce the type index duplication, but I'm sure it must be something similar.

I still don't know why this is happening, but that pattern of creating a new document adding a suffix is actually a Soukai mechanism to avoid overriding existing documents. The thing is that this should only happen for creating new documents, not for updates. So there must be something wrong in some part of the code that is trying to execute an update as if it were a new document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants