List of Ideas for improvement

Hello. fr33 asked if I could provide a list of ideas for improvement on here, based on what I experienced when I went through the tests, so others could discuss them. I would strongly encourage folks to provide any additional feedback on this thread for fr33 from their experiences.

Obviously, UI is probably the part that needs the most work, so I will probably focus on that the most, but the suggestions provided on this thread aren’t necessarily limited to the UI. FYI in advance: I’ll be using the terms “forge” & “code” below to reference the servers at and respectively, but don’t want to type everywhere. :slight_smile:

I’ll post each idea as a comment to this thread to allow folks to reply and discuss each idea separately.

List of projects: fr33 set up one project each on forge & code, but neither are reflected on the home page of either site. The project list needs to work, and it needs to reflect the projects on all connected servers (currently just forge and code). This will allow testers to navigate to the various projects.

Federated Data Needs To Be Shown: Currently, in order to create a ticket or comment on a ticket, one must copy over the URIs of the ticket and (if applicable) specific comment one is replying to. Instead (using a hypothetical), a user on forge should be able to find the project on code, view it through his feed on forge (meaning don’t simply take the forge user to the code website, where they don’t have login priveleges and wouldn’t be able to do anything), and have the UI to add/reply to tickets directly from that UI without having to copy and paste URIs.

Reply boxes need to be bigger TextAreas: Currently, the text areas for providing details is really small, so if you’re typing a long message, you can barely read any of it. They need to be bigger and more consistent across the various forms.

"Submit Query" Buttons: Using the word Query is not typically used on websites. Simply saying “Submit” is usually ok, or you could indicate what you’re submitting on each of the pages “Submit Ticket”, “Submit Comment”, “Submit Reply”, etc. To the common layperson, a query doesn’t refer to a SQL command, rather a question. If they’re posting a comment and see “Submit Query”, they’ll be confused, because they’re not trying to ask a question.

Side/Top Navigation Bar: Most websites these days have some sort of navigation bar, where there are common links that the user would expect to find on every page to help them navigate the site. Instead of adding on these types of links directly on the page intermingled with the links that help drive the user through the workflow presented on the page, they should be segregated into some sort of nav bar. I personally don’t have a preference on side bar vs. top bar, but perhaps others do.

URL structure: Currently, the URL structure is as follows:


It would be easier for users if we followed the URL structure found on most other code repository sites and eliminated the s & p:


This requires a dynamic client, of some kind. Web, desktop GUI, text based. Once I implement OAuth2, that will become possible to do. Help with this would be highly appreciated :slight_smile:

Hmmm on which pages do you see “Submit query”? Maybe your browser uses that label for buttons of type submit, that don’t have an explicit name? For me the buttons say “submit”. But yeah, for consistency they can all be named explicitly.

In Vervis, projects and repos are separate entities. It’s not obvious how to use such URLs. If I do use them though, I wonder how to keep the route tree clean and safe! And how to make sure weird usernames like “login” or “admin” aren’t used.

I’ve given some thought to this issue, documented here. What do you think about those options, and would you like to propose a new one? :slight_smile:

On Thu, 11 Jul 2019 15:01:01 +0000 Jason wrote:

I’ll post each idea as a comment to this thread to allow folks
to reply and discuss each idea separately.

FWIW, and IMHO, separate topic threads would be better for that
intention - i think nested threads within threads (replies to
specific replies) are unnecessarily confusing; and discourse is
not sophisticated enough to represent nested threads in its email
list as a normal mailing list would

for example, when discourse sends email, all messages are
linear, and will have merely the same subject:

Re: [Feneas forum] [ForgeFed] List of Ideas for improvement

there is no way to discern that any comment was a reply to any
other specific comment; and when replying, the only way to
indicate that, is by quoting the specific sub-topic in each reply

  • i tried that with this reply and it chopped off the quoted part
  • i had to sign into the website to correct that; so id say this tool
    is still quite quirky - maybe discourse will be able to represent
    nested comments in its emails someday; but for now we should
    probably avoid it - even on the web, the sub-treading is not

Hi, Bill. Thank you for the response. Sorry, this was my first time responding on this forum (I’ve never used Discourse before and didn’t even realize it was Discourse, tbh), and I didn’t realize the comment replies weren’t in some sort of threaded view. FWIW, fr33 asked me to just do one long post for all of these, but I was trying to find a way to spark a conversation for each one. I think your idea of separate topic threads is better, especially now that I see how the results turn out, and will use that in the future until the ticketing system in vervis is clean enough for folks to use.

Re: Federated Data Needs To Be Shown
For GUI/Text Based, I can understand why OAuth2 would be needed. IIRC, I believe Yesod already has the capabilities of handling OAuth2 directly (though there are packages specifically calling out OAuth2, so not sure if Yesod only handles OAuth1?), so this shouldn’t be too hard for someone to implement either way.

For web-based, though, one can already authenticate w/ Vervis directly, I don’t think OAuth2 would change whether or not this can be done now on the site. I’ll take a look to see if federated data can be shown easily enough with what we already have.

Re: "Submit Query" Buttons

It appears on all the forms (e.g., so I think you’re correct in that it is the way my browser [FireFox] is defaulting the button label.