-
Notifications
You must be signed in to change notification settings - Fork 119
Refactor apps to be an app launcher #930
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
Conversation
✅ Deploy Preview for musical-sawine-26ffa9 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
VirginiaBalseiro
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is removing the RDFa, which is a regression IMO. It would be great to retain (or improve).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Minor inline change request)
Cool, thanks for considering to retain the RDFa.
You know, if the markup pattern from the dokieli description is reused for all apps:
- we can extract more structured data out of this resource ( see for example https://solidproject.org/TR/#graph=https://solidproject.org/apps or see through http://rdf.greggkellogg.net/distiller for example.)
- they can also be reused for CSS selector, e.g.,
[property="doap:shortdesc"]instead of.app-description
Co-authored-by: Sarven Capadisli <info@csarven.ca>
|
I had a look at the netlify preview. I like the layout improvement! I also like that you're adding Dokieli, PodOS Browser and Solidflix to the showcased top section. Are you intentionally removing Solid IDE and graphMetrix from the showcase? Could you maybe add those two? And it seems you are also removing all other categories that now exist on https://solidproject.org/apps, leaving only the showcase. That feels like a regression and loss of knowledge. Could you maybe leave the other categories intact and only refactor the 'showcase' category? |
Nice! I like that idea. Maybe this can also be a push for end-user adoption and for the development of better fine-grained access control than what we have in place now. |
|
The criterias applied to featured Apps are:
I tested Solid IDE and did not manage to use it. It is currently being revamped and renamed as Solid Content Manager (see: https://github.com/jeff-zucker/solid-content-manager). I will check in with Jeff on that subject when he is back from his break later this week. The graphMetrix app is not compatible with solidcommunity.net. Presenting the wider ecosystem of Solid Apps is the goal of the Solid Catalog (all apps are present in the catalog's data). Here we want a simple, easy to understand and use entrypoint for people that are new to Solid. |
|
@matthieubosquet You'll be happy to know that the new template that @VirginiaBalseiro and I worked on marks quite a bit of the information in RDFa:
Here is a graph of those documents: Unfortunately, You may want to look over or pick up from: |
What is the definition of "simple user experience"? And is this assessment based on user testing? Can we have access to the data? It would be interesting to look at. The other concern with this PR is that there is information loss in that quite a bit of apps are dropped and there is no way for the community to discover them. |
|
There has not been user testing in the form you suggest. I spent half a day testing and verifying all apps on the current page to arrive at this shortlist. User testing is important and I hope that we get to do some in the not too distant future. It is out of scope at the moment but thankfully the assessment of simple user journeys from a layman's perspective is obvious enough. To remain constructive, @VirginiaBalseiro do you have specific usability concerns about the 4 featured applications that are greater than what you experience using the other 6? Is there an application among the 6 non featured that you consider easier or as easy to use as the 4 featured for someone that doesn't know Solid or RDF? As to the apps removed from this page, they are present in the solid catalog as per my previous comment. |
I don’t have usability concerns about the 4 featured applications, in fact, I haven’t used them. My question is more about the reasoning: why are these 4 starred and the others not? What criteria, testing, or data informed this distinction?
I can’t say whether any of the other apps are easier to use; I think that’s something we’d need to ask people without prior knowledge of Solid or RDF. In any case, it might be helpful to explain on the site what the star actually signifies. Otherwise, visitors might assume it indicates some form of verification or validation that the rest of the apps lack, when it’s really just a subjective classification. |
Requested changes were addressed.
|
I see your concern Sarven, I think you're right. |
|
Out of curiosity, @matthieubosquet would you say that dokieli requires users to have prior Solid or RDF knowledge in order to be used? What was your assessment of dokieli when you tested it out? |
|
@VirginiaBalseiro I think Dokieli is very powerful and I like the functionality. It's great that there are little screen capture videos to explain functionality. It is briliant that dokieli is embeddable (even though I haven't tried embedding it myself). The points I found most confusing (testing on dokie.li):
Finally, I think Dokieli is usable by people that don't know RDF but some understanding of Solid seems required which might be a Solid usability issue more than a Dokieli usability issue at this point in time if that makes sense. Or in other words is not unexpected for an application packing so much functionality. |
Annotations are not automatically loaded (unless the article has an inbox to help with discovery). There is a Notifications side panel that opens up when you click on an annotation (or by opening it up from the main menu). Do your annotations not show up here either? See: https://dokie.li/docs#feature-notifications . If this is the case, I'd be happy to follow up on an issue or in matrix chat. |
If interested, happy to continue on this elsewhere, but I'll keep this short: Users come into dokieli using their preferred identity, storage, inbox, outbox, and preferences (like type indexes) etc. All of that is configured outside of dokieli and so dokieli simply follows its nose. Different kinds of annotations could be stored at specific locations (as specified by the user's settings) or at the very least it will be stored at the root of their storage. There is more to this story - and yes, there is some configuration possibilities as the author of an article for example - but I suppose we can look into having a feature where the annotator can choose or know where stuff is stored. From the featured applications, are there examples of UX for authentication or storage that are more clear than dokieli's? Is Google Docs particularly clear in which directory the currently viewed document is stored or the location of the comments made by people? |
I hear you and we're on the same page. As I said, not a Dokieli issue per say. I'm sure we'll get the chance to continue elsewhere.
@VirginiaBalseiro I keep that in mind and will get back to testing Dokieli asap I'll follow up then. |
|
(Let me just say this last bit because it has been a recurring concern in the Solid community:) We're on the same page, but it's still unclear how the criteria for featuring apps is being applied, and it would help to know what apps would need to accomplish to be considered "acceptable". My two cents: the claim that Dokieli (or other apps) requires knowledge of RDF is inaccurate. In the case of dokieli, it requires no LD/RDF knowledge - it was designed in a way that's similar to what we can expect from an average user of an authoring tool like Word or Google Docs etc. I don't think there is anything underlying in Solid itself that would cause the apps built on it to require RDF knowledge either. The real issue is that most current Solid apps are proof-of-concepts built by developers to showcase technical points to other developers, rather than address real-world use cases, which is why they often expose complex technical concepts. It is easier to do that and develop a polished and well-thought UI when the application one is building has a very simple and narrow scope. It is much harder to do this when rapid prototyping (most apps around) or solving complex real world problems. I can only speak for dokieli but all things considered, it is aiming to be a valid alternative to solutions that have multi-billion dollar backing and billions of users (see Google Docs, Slides.. for example). So, not only dokieli predates all other apps that's actively developed (besides Tabulator / Databrowser, which are nowadays called SolidOS), it is quite literally a solution / response to a socially-aware application to give people a choice to move away from mega centralised platforms that take away people's control and power, everything from their online identity to their data. So, I suppose from our perspective, it has been very hard to understand what it will actually take Solid to thrive. Do we need more apps that are aesthetic and easy to use and simple to understand? 100% yes. But I think we need those apps to also solve real world problems, so that people will be compelled to adopt them for real usefulness rathen than just novelty. And don't get me started on the major shortcomings/limitations of Solid servers. The process here lacks consistent rules or metric. So, featured label may imply quality or validation. Would it make sense to flag this featured list and say that it is ODI managed ( as mentioned elsewhere, e.g., for newsletter? #932 (review) ) (I'll stop here and save the rest for a blogpost... and just to be absolutely clear, by saying all this, my intention is not to convince you to throw a star in our way on this page. In fact, please do not give us a star. I'm talking about the bigger picture / concerns here, and that needs a hard self-reflection in the community..) |
|
@csarven I understand and agree with your concerns. I have high regards for Dokieli and in fact I think that it does deserve a prominent place in terms of showcasing Solid. I don't think it is fit for first time users, precisely because it is a complex tool and despite the fact that in my personal opinion it is solving real world complex problems. Do you disagree? All the apps responding to the following clear criterias are on the app launcher as mentionned in my previous comment:
The selection of the 3 "featured apps" is entirely based on my testing of the 10 apps. I think they are outstandingly easy to use. Would you disagree? While I entirely agree that for Solid to thrive we need apps solving complex real world problems, the featured launcher apps are intended for first time users. Can you please let me know if any of the other applications among the 10 should be featured in your opinion? I am not proposing to solve the bigger picture here, just a small step in what I hope is the right direction for first time users. Do you think the notion of "featured" apps for first time users is detrimental to the adoption of Solid? |
Word/LibreOffice/Docs are probably the first app a person uses when learning how to use a computer. The complexity of a software tool is not relevant to the user; the complexity of a task is, and writing a text document is a pretty simple task with a lot of underlying complexity - and "good apps" hide that complexity. The same apps are also interesting to developers new to Solid because they incorporate operations about simple concepts, e.g., "create/update this resource". On a side note: there are significant challenges in interaction design for decentralized applications that are not exclusive to Solid. These are hard problems because in some cases it is not possible to directly map users' existing mental models to new paradigms. Through solving real life hard problems for users, we help contribute to figuring out how to tackle these challenges, but it takes time and work, and most of all: it takes people using our applications so we can find out what works and what doesn't. If we stay forever in the stage of poc/toy/example apps, we will never get there. We need to get out hands dirty and solve the hard problems. It also means we need to support those who are doing this kind of work, because in the end we all benefit.
Which one of these does dokieli not fulfill? Genuine question. I think perhaps (and I am only going by instinct here) featured apps are apps that perform a small or trivial task? I am trying to look at this from a (hypothetical) "newcomer" POV: I know nothing about Solid, click on an app that has the potential to let me replace Google Docs vs. I know nothing about Solid, click on an app that does something I don't normally do in my daily life (which begs the question, what problem is it solving).
That is a loaded question :) The answer is of course not. But it is also (very) subjective and arbitrary. In any case, I don't feel strongly about this list of apps, but it did pique my curiosity as to what the criteria was. Signing off and happy to pick up the general discussion elsewhere. |
@VirginiaBalseiro Dokieli is in the list. It fulfills all criterias. Have you checked the deployed app? |


This PR proposes a refactor of the Apps page on Solid Project .org.
The goal of this PR is to give first time users and visitors a simple entry point to try Solid through an App Launcher.
The 4 apps featured at the top ("Media Kraken", "Pod Pro", "Penny" and "UMAI") have a simple user experience that helps newcomers play with Solid without friction. The remaining 6 apps have been tested as functional and work against solidcommunity.net.
Apps can be sorted and filtered by category.
Eventually, we intend to prominently feature App Launching from the homepage.