#374 UX feedback on fedmenu
Closed: Fixed 2 years ago by duckution. Opened 8 years ago by ralph.

I [https://lists.fedoraproject.org/pipermail/design-team/2015-February/007092.html wrote to the list] about this back in February, but @mattdm [https://github.com/fedora-infra/fedmenu/issues/4 filed a ticket on the project] to touch base with the design team again, which is smart. It probably could use another round of conversation.

Note that we are [https://fedoraproject.org/w/index.php?title=Infrastructure/FY16_frontend almost done installing the shim] on all of our apps, which is awesome but it doesn't mean that we're locked into the way that it current looks, feels, or behaves at all. The shim just includes the js resource and makes a call to initialize it. We can rewrite the js/css to do anything we like (even if that something is "nothing"). :)

Questionnaire answers:

  • Timeline (when do you need the mockups / research data by? Is there a release or specific timeline you're targeting?)

No specific timeline. I'd like to evolve this chrome over time.

  • Who's the developer writing the code? (IRC nick + email + wiki profile page URL)

threebean, ralph@fp.o, http://fedoraproject.org/wiki/User:Ralph

  • Are you trying to make a pre-existing app better? We will work with you to determine the best methodologies to get you to that goal.

Kind of. See more below.

  • What is the application name?

fedmenu

  • How can we access it? (URL or package name / installer link, test user login information, screenshots, etc.)

There is a demo page at http://threebean.org/fedmenu
It is already deployed on some apps: https://fedoraproject.org/w/index.php?title=Infrastructure/FY16_frontend

  • Give us an elevator pitch for this application - What problem does it solve? What does it do, why would someone use it?

It aims to give a common feel to all our FI web applications with as little developer effort as possible. (We should work to do the high-effort things next).

  • Who uses this application? For example, is it aimed primarily at developers? Is it a command line tool used on headless servers? Is it an interactive web application aimed at desktop users with non-expert technical expertise?

Any visitor to Fedora web applications. I think these are primarily contributors.. but they are contributors of all kinds.

  • What are the main competitors to your app?

Two that I can think of:

1) a full on redesign of all of our apps individually that gives them a common look and feel (huge effort)

2) a rewrite of all of our apps into one app that has a unified look and feel (huge effort)

  • Are you trying to build a brand-new application?

Kinda. It is a javascript shim that is kind of like its own application. But it is small and client-side only and different from all our other apps in the usual ways.

  • Is there any testing or development code available? How can we access it? (URL or package name / installer link, test user login information, screenshots, etc.)

Check out

1) https://github.com/fedora-infra/fedmenu for the source

2) http://threebean.org/fedmenu/ for a demo

3) https://apps.fedoraproject.org/datagrepper/raw?user=adamwill&package=firefox for a live example


For the record, I was super-complainy in IRC today, but actually am completely onboard with the goals of this little project and do not mean to undermine it. Let's just go for Maximum Awesome.

I have two broad concerns.

The first is that the floating F seems somewhat intrusive and may be off-putting. Its constant presence even as I scroll implies that it's something that is going to be constantly useful and relevant.

The second (and I guess related somewhat to the second part of that) is the contents. I think the focus should primarily be on users (and in this context users is often "contributors"), with the list prioritized for that (and maybe with more descriptive names?).

Longer term, and going to that "always useful and relevant" point, it'd be interesting to have this serve as a notifications inbox. Have it light up in some way when I've got a message.

If it could be done medium term, one thing that'd be specifically awesome is new badge notifications. Show me when I've earned something, and the last few badges I've acquired.

Replying to [comment:2 mattdm]:

I have two broad concerns.

The first is that the floating F seems somewhat intrusive and may be off-putting. Its constant presence even as I scroll implies that it's something that is going to be constantly useful and relevant.

Cool. Easily, we could make the F much smaller so that it is less intrusive. That's a quick-fix response.

I'm definitely open to other ideas of how to change or re-do it if we come up with some (I just can't think of any.. or, the floating F is the best idea I could come up with).

The second (and I guess related somewhat to the second part of that) is the contents. I think the focus should primarily be on users (and in this context users is often "contributors"), with the list prioritized for that (and maybe with more descriptive names?).

We have more descriptive paragraphs of each service already in the data source, so we can use those right away if we can figure out how to situate them in the menu. It felt too cluttered when I tried it early on, so I backed out and just stuck with the name. We also have icons for most of the services, but not all. I ended up leaving those out too so that it would look less 'patchwork'.

You mentioned in the github ticket about the order of services there currently. It is super easy-fix to just re-order them or hide some if we think "no one will want to know about this particular one".

Longer term, we can totally re-org how info is presented. I guess we just need some ideas about what else to do. Presenting the list of all services seemed like a good go to me as the guy who had to figure out the entire service-surface of fedora infrastructure in order to do the badges project. In that process, I realized that it wasn't documented anywhere and no one actually knew what the sum total was. Having that list is valuable to me.. but it's certainly arguable that it's not useful for the casual wiki visitor or fedora user.

Longer term, and going to that "always useful and relevant" point, it'd be interesting to have this serve as a notifications inbox. Have it light up in some way when I've got a message.

If it could be done medium term, one thing that'd be specifically awesome is new badge notifications. Show me when I've earned something, and the last few badges I've acquired.

Both of these are cool ideas but they both involve a technological leap that's not all that simple. This javascript shim would have to know about your login status and who you are. We might be able to pull that off by checking for a cookie from id.fedoraproject.org (the tricky part that might not get in our way is that almost every one of our 30-some apps represent user-login differently). I'll talk with puiterwijk about it. It makes sense for fedora-hubs to be the data source that gets queried for "stuff for you".

we had a discussion about this a couple of design team meetings ago - IIRC the conclusion was that fedora-hubs is definitely going a be a big influence on how this evolves. It might be worth carving some time out during the design team clinic at Flock in August (since hubs will be further along then) to rethink some of the components here.

we weren't able to discuss this at flock; that being said, i don't think it's super-urgent, and i think it might be a good idea to wait for fedora hubs to further develop before tackling this one. seem fair?

@ralph, it has been a while on this one, what is the status of Fedora Hubs in regards to this ticket? Should we begin work?

Thanks for the ping! We don't have any further progress on fedora-hubs yet. Give us another 4 months. :)

If it is troublesome to have this ticket in your queue, we could always close it and re-open it later.

@ralph, any updates here?

Scratch that, we are going to wait to figure this out until after Flock :)

still waiting on hubs prototype to start thinking about this

we have a very rough cut of hubs in staging, might be a good time to start thinking about this.

Metadata Update from @duckution:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata