Focus: A Solid Task Manager


#8

Awesome work, I have just some UX pointers if you are interested to hear them, PM me on Gitter or LinkedIn.


#9

Great app, @NoelDeMartin, very nice work! I think starting with the Schema types, as you have is good - likely to be widely recognized. As you add more features, you’ll need to look at more specific ontologies likes calendars and events.


#10

Nice app!

Question, can I save tasks to my Pod?

A key pattern with Solid-based RWW apps is that the WebID-Profile doc of an authenticated User Identity should inform said app about about Data Storage location. Here are some WebID-Profile doc relations that are currently associated with this pattern, via my WebID-Profile doc:


#11

As far as I understand, as long as you login with a solid account (instead of using the offline mode), tasks will be stored on your pod, right? My understanding of “pod” is the solid server. For example, one account in solid.community.

This is something I don’t know about and I think it may be related with what @pheyvaer was talking about. I’ll look into it and if I’ve got some doubts I’ll let you know. Thanks for the links :slight_smile:


#12

Yes, this works fine. When creating a workspace, it shows my storage https://angelo-v.solid.community and then I can choose a name for it. I can then find the data at https://angelo-v.solid.community/<name>/


#13

When I am logged in I should be able to see my WebID as a hyperlink that anchors my literal label.

The pattern for this is <a href="{webid}">{object-of-foaf-name-relation}</a>.

In addition, it would be beneficial to inform the user about default storage via pattern:

<a href="{webid}">{object-of-foaf-name-relation}</a> default <a href="{object-of-pim-storage-relation-or-ldp-inbox-etc}"> storage </a> .


#14

Can you elaborate what’s the benefit of doing that?

About the storage, I still have to read a couple of links that have been posted on this thread to learn what storages are. Once I know them, I’ll see how to approach your suggestion :).


#15

It takes one mouse-click or a mouseover to see what Identity your application is working with :slight_smile:


#16

Shouldn’t that be seen with the name already? Unless you have the same name in different servers (which I guess is common).

The problem I see with placing the link on the name as it’s implemented now, is that it is displayed on the navigation drawer at all times. And I’m not sure if I’d want to add a link in there just for this reason. Maybe what I can do is include it on a “settings” panel or others that I plan to include at some point. Basically I agree that this information should be accessible somewhere within the app, but I’m not sure if the navigation drawer is the most appropriate place.

Thanks for your feedback, I’ll think about it and let you know once I’ve added this :).


#17

Key thing is for a WebID (an HTTP URI) to exhibit the characteristics of this kind of URI :slight_smile:


#18

Thank you for sharing this great example and your learning experience Noel! I very much appreciate your activity log. Very useful and inspiring.


#19

Thanks! I’ll be starting the continuation shortly where I apply some of the feedback and I’ll look into a better way to handle the data models :).


#20

@NoelDeMartin great job on this app! If you’re still interested in exploring other ontologies, my team works with the Common Core Ontology. I know that we have some detailed task-related terms. If you’re interested in giving them a try, I think we could add some additional features to your app (like due dates etc). Let me know if you wanna give it a shot, we’re happy to help.


#21

That’d be great! I’ve actually been working for a while in a dev branch adding new features, and finding ontologies is still one of the main pain points. I’ll add descriptions (already implemented) and due dates to the next version, and I wouldn’t mind changing the ontologies because there won’t be a 1.0 stable version yet.

You can check out the ontologies I’m using at the moment here: https://github.com/NoelDeMartin/solid-focus/blob/dev/docs/README.md#data-schema


#22

Great, I’m checking them out now!


#23

It’s strange for me to use foaf:name for a Task or a List… I thought it was reserved for a Person, a friend of a friend.


#24

@NoelDeMartin It won’t be a problem at all for us to have our ontologist put something together for this app. It will be a few weeks though because he is a contractor and we are currently waiting for the budget stuff to finalize. As soon as he’s back on the job I’ll let you know and we can continue from there!


#25

Yes I agree it’s very strange, but quite frankly I know almost nothing about how to use proper ontologies and property names :/. I’m of course open to suggestions thou :D.

For example, it was hard enough finding an ontology that had something like “tasks”, so I ended up with these two: http://vocab.org/lifecycle/schema and https://www.w3.org/ns/prov but I didn’t find anything on how they name the tasks/activities so I just assumed foaf:name was ok because I’ve seen it used in many examples (yes, they were probably only examples about persons).

The only ontology I’ve found that makes sense to me is schema.org, but it didn’t have anything about tasks. I hope that I’ll be able to fix this with the help of the community :D. I was focusing on implementing the code first, but for sure before having a stable version of the app I’ll try to have this sorted out.


#26

I’m working on an app that also uses tasks, so I’ve been trying to work out how to make it interoperable with Focus.
It seems what is needed is:

  • look up the Pod to store data in using pim:storage, because it might be somewhere other than the profile doc, e.g. for performance or bandwidth reasons
  • look up the container to store tasks in using type registration. If there is no container specified, then suggest a default and let user override it

If my app then does the same, then we’ll both be able to find the tasks wherever they are.

I pieced this together from:

Corrections are welcome.

However, it’s not clear that the type registry is a final solution for interoperability between apps. I’m not sure how it fits with: Blog post: Shaping Linked Data apps


#27

Yeah, basically what I do for reading/creating tasks is read the containers indicated by pim:storage and I create a “Workspace” to store the tasks inside. This workspace is basically an ldp:Container with the lifecycle:TaskGroup type. You can see the schema of the data here, but it’s possible that it’ll change given that I’ve had some issues defining the types as you can see in the last comments on this thread.