m8b

Countdowns!!!!!!

My plan forward is:

I am bad at code review :(

dafuq?

question

um

I pushed that junk here, yell if anyone catches issues.

I sure wrote some Javascript today

Actually, I'm slightly wrong about dropdowns-in-dropdowns being the issue, looks like some kind of rendering order problem instead.

Dropdowns need a bit of CSS tweaking but they feel OK to me.

e.g., pretty sure we can do slightly better than this without resolving any big philosophical questions:

We can/should also make hovercards richer -- I think that's mostly "free" in terms of product/design tension, especially for cards like mocks which have received very little attention.

oh, yeah derp. single line with more info would kick ass

Yeah, I'm leaning toward starting there too.

Oh, I wouldn't plan to make them meaningfully taller vertically -- I'm primarily imagining a very small adjustment ala "Reviewers" in Differential, e.g.:

Let's start with the two dropdowns and see how it goes.

I go back and forth on if Tasks/Revisions/Commits should be richer. I do think maybe we can leave them as a list but have a button/dialog to pull up their full cards? My main concern UI wise is they'll take up a ton of space on larger tasks and really force the content down.

Yeah, I think that's totally reasonable. I want to fix up the UI for showing subtasks and revisions and stuff as part of T4788, so I'd expect to do this:

I'd probably turn this into two sections (I guess?) if we had a dropdown/disclosure element:

I was sort of hoping to make Pholio (for instance) a rich panel in the main column. So if I attached M1464, I would get a Pholio Panel with

Some ideas here:

Are customizing styles and retaining the Phabricator brand altogether mutually exclusive?

Specifically CelerityPostprocessor will let you globally change probably 99% of colors, backgrounds, and fonts. Then your local users can either select the built in default or the optional one you just built.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.

It seems to me that exposing a few classes for regular html colors, and a config form for editing them would not be such a killer big deal.
Form -> Header Color #______
Phabricator CSS -> .header_color { color: YOURCOLORFROMFORM};

Just bookkeeping; this doesn't have an active external priority driver.

ɯɯɯɯɯɥ

hmmmmm

hmmmmm

(And those UIs might also not actually be useful for future-administrators, particularly since I don't really plan to ever help users with third-party stuff, although who knows.)

My intent with a lot of that stuff is to make administration and support (particularly in the future, once third-party applications are more common) easier, so they're targeted primarily at future-administrators who have questions like these, possibly because we've asked them for the information:

Some things in the side bar seem more deleoper related than configuration related. Trying to think where we could possibly move then maybe, like a developer app?

(And we can continue reducing the number of settings, but not very quickly.)

/config/ is already an attempt at chopping it up, vs /config/all/ which is the un-chopped version. If you have a better way of making it less scary there's no need to chop it up in the way it's currently chopped up, though.

Also "Config" is super scary. It might be helpful to chop that up a bit?

Thinking about the "Phacility" NUX case and unsure users really need to explore Config or Applications. Really we just want them to invite some people and pull in their repo. If new to Phabricator... learn about getting Arcanist up and maybe make a few projects. I'm mostly trying to separate things into "must do" and "useful tips". Useful tips can just go into Feed as the first post, like Quick Start guides for individual apps or following us on Twitter.

whew, only took a few tries

wth with the remarkup

You can test with "Discovery" at https://phabricator.wikimedia.org/

Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:

Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).

The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:

I can remember trying to file a bug against Safari when I worked at Apple, seems like a simple task. But typing "Safari" came back with 50-100 tags... I had no clue as a first time filer what to fill out. A short description might have helped, perhaps. But overall I guess I'd like to understand what users are ending up at the browse dialog to begin with. In the Safari case, having something like Nuance is better for the novice user than asking them to wade through 50 results and guess the correct one. I want to basically make sure we understand which user we're helping here.

I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.

Would definitely like the ability to swap out the eye via config à la wikimedia install.

We can clean this up for phortune a bit better.

This is the expected method.

BTW is the print action the expected method to get an "invoice" for my records? Or can you download a formal invoice from somewhere?

My example for this problem was with Maniphest tasks in T10790, where identical task titles is problematic in the search results.

✂✂✂✂✂
✄✄✄✄✄

needs a haircut

yea i noticed that.

Hi all, glad to see this issue is being looked at. Per my task in T10641, simply having "all documents" search show the same style of content as is seen in Maniphest search would speed up our day to day, as most people on our team use all documents search (unintentionally, as it is the default), even though all they really care about is Maniphest, and so their experience isn't great here (their impression is "Phabricator search isn't good" which I think is related not to functionality but discoverability and smarter default configurations).