Pulling a random project for example, in https://sr.ht/~welt/murse/ I
can click on links for the git, lists, and todo pages for murse. None
of these pages link back to the main URL for the project, so if I want
to visit it again I need to use the back button in my browser. If I
visit any of those pages directly or from a link from a different
page, I have to manually edit the URL to remove the git.*, lists.*,
etc. It would be nice if those pages had a link back to the main page
for the project. This applies to user pages and their git, lists, todo
etc pages as well.
andrew spada <spada.andrew.j@gmail.com> writes:
> Pulling a random project for example, in https://sr.ht/~welt/murse/ I> can click on links for the git, lists, and todo pages for murse. None> of these pages link back to the main URL for the project, so if I want> to visit it again I need to use the back button in my browser. If I> visit any of those pages directly or from a link from a different> page, I have to manually edit the URL to remove the git.*, lists.*,> etc. It would be nice if those pages had a link back to the main page> for the project. This applies to user pages and their git, lists, todo> etc pages as well.
The "problem" is that all those services are not coupled. Creating a
project doesn't necessarily force you to also create a git repo, a hg
repo, a tracker, a list, etc. You can choose whatever you need and want
or use the same tracker, or mailing list for all your projects (e.g.,
your public inbox). And even when you use all/many services for your
project, there is no need that project, its repo, and its bug tracker
have the same name, so you can't just take the project URL and add a
/todo/ somewhere and be sure to reach that project's bug tracker.
So IMHO, it's the responsibility of maintainers to link all resources
together in the descriptions / README.md files so that navigation
becomes easy. And that makes sense anyhow, e.g., to that a user who
cloned the git or hg repo has the links to tracker or the mailing list
locally, too.
Bye,
Tassilo
On 17-06-2021 07:01:31, Tassilo Horn wrote:
> andrew spada <spada.andrew.j@gmail.com> writes:> > > Pulling a random project for example, in https://sr.ht/~welt/murse/ I> > can click on links for the git, lists, and todo pages for murse. None> > of these pages link back to the main URL for the project, [...]>> The "problem" is that all those services are not coupled. [...]> > So IMHO, it's the responsibility of maintainers to link all resources> together in the descriptions / README.md files so that navigation> becomes easy. [...]
I agree, although a mechanism to add these links manually wouldn't hurt right?
E.G. if I have a repo which has a todo tracker, enabled builds and a
public-inbox list where I collect patches for a number of projects, there could
be an option in the settings for the repository to add a link to the
repository-page that links to the todo tracker, the builds or the mailing list.
Having these things uniform in the interface (the same look / location of the
buttons for all projects, if they choose to have these links), greatly improves
navigation speed for users of the web interface, IMO.
--
Matthias
Tassilo Horn <tsdh@gnu.org> writes:
> The "problem" is that all those services are not coupled. Creating a> project doesn't necessarily force you to also create a git repo, a hg> repo, a tracker, a list, etc.
While this the correct rationale, I think (and that's imvho) that some
users (like OP) expect a more integrated experience in sr.ht since we
are all used to how other forges work: using accessory services is not
mandatory but if you click somewhere you are prompted to activate that
service (which you may or may not want to do, but at least you know it's
there). The UX is globally more consistent and services more
discoverable.
So I hope that as sh.rt evolves, its UI also improves accordingly in
this regard.
Best,
On 6/17/21 1:01 AM, Tassilo Horn wrote:
> andrew spada <spada.andrew.j@gmail.com> writes:> >> Pulling a random project for example, in https://sr.ht/~welt/murse/ I>> can click on links for the git, lists, and todo pages for murse. None>> of these pages link back to the main URL for the project, so if I want>> to visit it again I need to use the back button in my browser. If I>> visit any of those pages directly or from a link from a different>> page, I have to manually edit the URL to remove the git.*, lists.*,>> etc. It would be nice if those pages had a link back to the main page>> for the project. This applies to user pages and their git, lists, todo>> etc pages as well.> > The "problem" is that all those services are not coupled. Creating a> project doesn't necessarily force you to also create a git repo, a hg> repo, a tracker, a list, etc. You can choose whatever you need and want> or use the same tracker, or mailing list for all your projects (e.g.,> your public inbox). And even when you use all/many services for your> project, there is no need that project, its repo, and its bug tracker> have the same name, so you can't just take the project URL and add a> /todo/ somewhere and be sure to reach that project's bug tracker.> > So IMHO, it's the responsibility of maintainers to link all resources> together in the descriptions / README.md files so that navigation> becomes easy. And that makes sense anyhow, e.g., to that a user who> cloned the git or hg repo has the links to tracker or the mailing list> locally, too.
Maintainers have already coupled together their resources when they use
the project hub.
The inconvenience noted by the thread OP is a known issue with
sourcehut, and acknowledged as incorrect and bad UX.
It is simply that, well, sourcehut is still in alpha, remember? And
there is a ticket for project resources (git, lists, todo, etc) to
linkback to the project hub they are attached to, for navigation purposes.
The ticket is even marked as a beta blocker. It's important enough that
it's a requirement for sourcehut to graduate from alpha to beta. That
makes it pretty darn important, don't you think?
https://todo.sr.ht/~sircmpwn/hub.sr.ht/15
So we can all stop discussing this, I think. sourcehut itself has spoken.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
On Thu, Jun 17, 2021 at 09:14:41AM +0200, Matthias Beyer wrote:
> I agree, although a mechanism to add these links manually wouldn't hurt right?
I've got a homemade solution for this that might be interesting for
you? I know, not perfect at all, but I think it is helpful.
If you take a look at my own hub,[1] I take advantage from Markdown
support in profile descriptions. I've included two navigation links
that I think are what I need. Anyhow, maybe you could use this to
create a navigation menu tailored to your needs.
And yes, sometimes we forget sourcehut is still in alpha...
Cheers!
Ari
[1]: https://sr.ht/~arivigo
--
Ariadna Vigo
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD
I've had many times, where I've wanted to navigate to a service I know
exists for a project.
I go looking for it, many times clicking on the top left, thinking 'here
it lists services available for this project', yet it redirects to
something like todo.sr.ht instead.
I have to navigate back, look again (now I skip this step), and then
edit the URL, removing the path (while keeping the slug), and changing
the subdomain.
Not going to argue whether it's the maintainer's job to link them in the
README. If they were linked there, global navigation is still lacking.
(Navigating from say lists to the project's git, to readme, to something
else.) Not even mentioning discoverability.