Learn more about these different git repos.
Other Git URLs
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:
No specific timeline. I'd like to evolve this chrome over time.
threebean, ralph@fp.o, http://fedoraproject.org/wiki/User:Ralph
Kind of. See more below.
fedmenu
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
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).
Any visitor to Fedora web applications. I think these are primarily contributors.. but they are contributors of all kinds.
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)
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.
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).
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?
Agreed! Thanks. :)
@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)
Login to comment on this ticket.