Feedback on the current version #51
Comments
|
Thank you very much for this detailed feedback. It is very helpful. I will keep updating and discussing here as I work on individual suggestions. |
Amazing, thank you very much for the very detailed feedback.
Didn't they completely remove support from HB 2.0 earlier this year?
I would be slightly more in favour of de-capitalizing things. Maybe start with uppercase, but then continue with lowercase. That said, I'm not a native speaker, but I agree that consistency is important (I just didn't want to nitpick too much so far).
Yes, only those users who opted in are counted. We should continue working on getting more users opt in. But until now we didn't have that much to show, so we didn't spread the word as much. We've had http://stats.macports.neverpanic.de/ since a couple of years, but that one had some serious database design flaws that made the statistics semi-useless, and we didn't have any serious expertise in ruby on rails, so nobody submitted any serious patches. I hope this will change now, and we should be able to advertise more.
I leave it up to Arjun to decide what to do. We already have something written, but maybe it should in fact be made more clear that we don't just have 30 users in total.
With many mirrors in place and a generic attitude that we don't want to spy on our users, this will be impossible to get. But we could provide some other metrics like monthly download volume etc. I don't have access to those.
Yes, maybe 10 makes more sense. And the
To some extent I find browse-by-category semi-useless, in particular on the first page taking up the most valuable space. See also #47.
Yes, that would be one of my requests as well if we keep showing that list. A single database query should be sufficient to retrieve all categories together with the number of ports in that category.
Good point. Maybe we can add this to #47.
As well as "Contribute" with links explaining how to improve the site :)
This is something that needs to be corrected "upstream", in the (Most
Agreed.
Agreed.
What about a cross at the end of the input field?
We were discussing this a bit :)
We could definitely come up with something better, but
This means that we have no data about the builds. This may happen for various reasons:
Please complain to upstream :)
No, it's not a date, it's really supposed to function as a version. But you'll find numerous packages having dates as part of the version. Sometimes that's the date of the commit being used, in particular when there is no version / no tag for that commit. Sometimes upstream simply decides to use such versions. A software I regularly use makes daily updates, sometimes maybe ten times per day (by a single developer). The developer simply decided to use YYYY.MM.DD for version string as there are no bugfix branches or tags or whatever. Just a "rolling release". (Also, I'm not sure if slash is even valid in version specification.)
I would replace this by
I wanted to suggest a change a while ago, but didn't want to distract Arjun too much with unimportant things at the early stages of the project. I would remove this line and draw a lock (maybe just take a symbol from one of the web fonts) next to maintainer. When you point mouse over the lock it would provide a hint explaining what this is (opposite of
Yes, that's a special meaning. Actually all ports should have the
The only way I see to make this generally discoverable would be to offer some universal search filtering functionality where one could apply any criteria (search for port name, ports belonging to a particular maintainer, having a particular variant, being requested more than N times, being broken on a particular OS version, ...)
Looks like a bug (that might be trivial to fix).
Maybe we need to provide some hints. We would likely need one single page explaining the concepts in more details and then provide links to that page. To answer your question: runtime dependencies are tools like "python" which you might need to run your script, but you don't need to link against the python library itself. Or maybe you need In contract, if you want to use Runtime dependencies may in principle not be needed when building the port, and this could optimize the build speed.
@mf2k recently requested right alignment. This might stay confusing to some extent independent of how we do it :) I cannot decide what would look better.
I'm not sure how without making the search results semi-useless due to its potentially very long length. Also, many ports cheat and provide just one (long description being the same as the short description). This would also make rending slower, of course.
I would make this a low priority to maybe experiment with once other things are done.
This might belong to category of "we need to explain some term". Some ports are important because "the whole world" depends on them, even if nobody explicitly installs them. Other tools are important because users want to use precisely those tools. There is a significant difference between the two.
That's because we have only been receiving submissions for just a tiny bit longer than a month.
All choices are pretty random, to be honest :) While we could add "All times" / Total, I don't expect super useful results for that. It makes more sense to then draw time charts showing how various parameters kept changing over time. Something between 1 month and 1 year still sounds reasonable, as the factor is quite large. We would write 3 months, but duration of a month is ambiguous.
That's totally expected because we don't have any statistics older than 2 months.
We just discussed that our wording is misleading and we need a better way to word this. Suggestions welcome. 365 days starting 180 days ago means the interval (-365-180, -180).
We would like to keep the second option. It lets you check the previous month (excluding the last one) and compare it with the last month. But wording should be improved. (Actually, you could also easily submit the change in wording yourself by submitting a pull request But that code is still undergoing code review and fixes, so it is not yet in the master branch. Once it will be, I can send some links.)
Just those who opted in. We don't track users, so there's nothing else.
Note that gcc9 is out. We may need to add the total number of unique users submitting statistics during the same period of time for comparison (30), and then maybe also write the percentage and rank (like: this is the 850th most installed port (16.75 %) and 85th most requested port (10 %); ordered and worded differently, of course).
Given that we only have statistics for June and July, any graphs will be straight lines by definition :) Maybe wait at least until around the 10th of August to see something more interesting?
The authors will see new installations with up to one week of delay (down to zero delay if super lucky). For that we just took the work from another GSOC student from around 2011. The submission process could be improved later, we just didn't feel this was the highest priority to get the basic work done.
For that we would need to actually submit immediately after port installation happens.
This might significantly change once we switch to the new buildbot.
Adding table header should be relatively easy. Actually, if you feel like making the first contribution to the project, you could add them here and submit a PR :)
They are ordered by time.
I agree, but maybe not just yet as there are more important features pending for implementation, and this one would take a bit more time to be implemented in a clean way, and would likely not be of much immediate benefit. What I would mainly like to use this table for is to check whether recent builds have failed. What would be a more useful change to that table right now would be to update it more frequently.
Or simply some shorter version of "Number of (opt-in) users submitting statistics" or "Number of participating users". The "vs. month" part is evident from the graph. And I would probably remove the legend.
Not the title, but useful hint for users.
Which of the titles?
Yes, that would be helpful.
Submission: each time the user submits the data (usually 4 times per month, or less in case the user was off-line). It can be submitted manually more often than that. User may accumulate tens of hundreds of submissions. Unique users: that should be clear, at least. The number of unique users who ever submitted something. That said, of course one user may have 5 computers submitting statistics, and that would count as 5 unique users. Yes, we probably need to explain in detail about how submissions are done. But I would do it in a document in repository, not deploy it to the site.
Feel free to provide feedback also on those you didn't find :) (Seriously though. I'm curious what would be the number one missing feature, for example.) |
You are welcome, happy to help.
No idea, it doesn't even tell me its version: ➜ ~ brew --version
ERROR: Your version of macOS (10.8.5) is too old to run Homebrew!
/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby: invalid option --enable-frozen-string-literal (-h will show valid options)
ERROR: Your version of macOS (10.8.5) is too old to run Homebrew!
==> Downloading https://homebrew.bintray.com/bottles-portable-ruby/portable-ruby-2.3.7.mavericks.bottle.tar.gz
Already downloaded: /Users/dmitrizaitsev/Library/Caches/Homebrew/portable-ruby-2.3.7.mavericks.bottle.tar.gz
==> Pouring portable-ruby-2.3.7.mavericks.bottle.tar.gz
Error: Failed to vendor ruby 2.3.7.
Error: Failed to install vendor Ruby.
➜ ~ Not exactly the most helpful message of my life :)
Thank you for this advice, I had actually stumbled on the C11 support issue that brought me here: But I wasn't sure how to follow the instructions:
How can I see which of my ports are using C++?
Can I try it or something else without removing the ports first (that took hours to build)?
This is a concern for me if building from source will fail.
That reads like some dark intentions by Apple to impede my functionalities, is it? Here is my current state: ➜ ~ port installed|grep "libc"
clang-5.0 @5.0.2_3+analyzer+defaultlibcxx+libstdcxx (active)
clang-6.0 @6.0.1_2+analyzer+defaultlibcxx+libstdcxx (active)
clang-7.0 @7.0.1_1+analyzer+defaultlibcxx+libstdcxx (active)
clang-8.0 @8.0.0_0+analyzer+defaultlibcxx+libstdcxx (active)
libcomerr @1.44.5_0
libcomerr @1.45.2_0 (active)
libcroco @0.6.13_0 (active)
libcxx @5.0.1_4 (active)
➜ ~
That would be another way to make it consistent but might miss out on the readability advantage of the capitals to call user attention to the nouns, away from propositions. Are there advantages to de-capitalize all words in labels?
Now it comes to my mind that some of the biggest user frustrations that companies ignore or unaware are providing search options with empty or too few results. It is probably better to disable them by default until enough data is there, or at least give some clear warning
I can't think of anyone objecting to collecting and showing total numbers of downloads. And to address people's concerns, I find a dedicated privacy page linked from each page's footer doing generally great job users appreciate.
Yes, linking to total stat is always helpful from any partial stat page.
Thanks, will reply there...
The footer should be the same on all pages, so it might not fit into the landing page discussion?
Spot on :)
The easiest way to begin would probably be just linking it from there, with some short explanation about the differences. Then people can use whatever they like. I would certainly not recommend removing anything from the old site, that might "feel redundant". This is the mistake made by so many companies that always make people angry because it disrupts their workflow even if the new site is (in the company's view) "much better".
Yes and no. :) For instance, you can always add a comment or two beyond the upstream version.
I certainly wouldn't want to add to people's work, especially to volunteers.
Indeed, that is the standard simple way and probably the best.
The default white cross on grey is probably the best, plain and simple. The trashcan and all other icons I would stay away from in any no-nonsense project :) One extra feature that might be useful though is to turn the cross into "Undo" when clicked, to account for the user clicking on it by accident to quickly recover the last search. Better than retyping it again from scratch.
That will work too for any tech crowds, which is the case here.
Are these not versions? This is how they look to me, if they mean something else, that would be definitely good to mention :)
That sounds like a reason to explain all the notation, similar to how you already nicely do it for the stat colors.
Thanks for clarifying. I would probably suggest then to link to a page where these are explained. Even just a page stating what you said here will work :)
So the search only refers to history, not the actual database?
That would also be helpful to explain with a brief note. Not having such wishlists is IMO a mistake made by many projects wanting to encourage new contributors. There are sadly too many project owners out there not acting welcoming to new contributors, so people get discouraged and may think twice before investing their time in what might later hit the wall of rejection. And given how many people use this project, and how Homebrew is going nuts and people like yours truly coming over here, that might work really well. :)
About the version notation? ... and of course, feel free to submit a PR for an update as it apparently hasn't been touched for a while.
I wouldn't know where, as it doesn't seem to link to GH?
Wow, really confusing though.
That is ok, as long as they are recognizable as dates :)
I see where you come from, and you certainly don't want to impose anything on the port authors already dedicating their time. But on the other hand, there might be some minimal agreement needed to avoid confusing end user, that may reflect on the project itself. For instance, one simple way would be to require to either begin with a version number or, if they really hate those, just prefix with some "v" followed by whatever they want.
Or any of
Absolutely. :) In these cases, any info about the actual state of the project, whether a new maintainer is desired and possible alternatives would be helpful. It is always frustrating to see projects that look "dead" without knowing which one of the following is the case:
That page doesn't seem to use the "Closed Maintainer" terminology...
Removing is always a simple way, whenever you have other higher priorities. :)
So your suggestion is to default to "Open"? Sounds like a good idea to me :)
That must be totally confusing to me as I've thought "universal" here is the name of an alternative port :). So "Variants" is a label (that sounds like alternative) and "universal" is content, i.e. the alternative port. :) Still can't make sense of that long list though, what is it good for...
It would be nice to have all the search pages easily discoverable from the landing page. Otherwise, it might be frustrating to find that nice page I've just seen and closed. Just having a simple list of links on the landing page to all already existing search facilities might work just fine, then you can always enhance it later if you have the time. But I'd be wary to regard as "discoverable" any "fancy stuff" that would only appear after certain actions.
Hopefully, but it is actually not the first time I've seen it.
Is this for the installation runtime? Or running it as binary after? Will certainly help to have an explanation of this terminology.
Isn't it already used for all ports after downloading?
"Link" here means creating a symlink?
Optimizing speed would be welcome as some ports seem to take what feels like hours to build. Especially if it takes so long, giving some approximate time would be very helpful, if it is not possible to show any detailed progress like with downloading.
That would feel confusing to me, why that label is left- and that other is right-aligned...
Just truncate text whenever it is long, followed by the "more" link is an easy way.
Cheat... how could they? :)
How?
I see. That sounds like downloaded as dependencies. However, I have recently experienced ports breaking installation when being indirectly requested as dependencies, while they would perfectly install directly with
I see. It is true that sometimes it is good to know the difference, instead of just seeing all downloads like with
Then maybe disabling any control leading to empty results? Currently there are too many choices and keeping clicking with no use can be frustrating.
True. If no one had used them for a year, it is probably better not to use them.
It depends on how many choices are there already. Anything above 3 would feel too many IMO.
I wouldn't exactly regard them as a masterpiece project to follow, after years of a frustrating experience. Also, their aggressive stance of support-dropping and insisting on upgrades is rather disconcerting. I feel sad to see it mentioned everywhere as the first choice, which is not necessarily in users' interest.
And to me, it means
I wouldn't even know the use for any interval not ending with 0. That is, "last X years/days/months" would seem to cover all needs I could think of.
Sure, if I know these changes are welcome. :)
Because the latest version could be broken on my old system?
I hope it won't take away too much of your time. :)
But your data are spread over these periods, aren't they?
I personally find the OSX versions most interesting, being, unfortunately, a big painful issue. (In the ideal world, would shouldn't even have to deal with it.)
I understand this is related to that voluntary submission, but many users might be concerned about their privacy. Instead, maybe the real downloads statistic with some simple transparent privacy statement as I mentioned above?
Then maybe just removing it, so no one asks :)
Then maybe briefly mention it.
True, this wouldn't of high priority. Maybe mention in the wishlist of desired future contributions (if it is).
I find the TravisCI interface really clean. Are you using it? Or something similar? Then possibly just link there instead of any duplication of they already have?
Indeed, time classifier may be unnecessary.
But it appears like a title.
For the list on the right.
Indeed, a Github link is even better.
That would just be 5 downloads for me.
Ah, that's interesting perspective :) One thing I notice is the API endpoint Another thing is their search is powered by Algolia, with no sign of What I find nice, are links to Github repos everywhere, which can be really useful if you want to check out the status or contribute. All-time periods are measured in days only: Feels simpler than day/month/year perhaps. The analytics is basic and mentions only "Install Events" for what looks like total ones. Links to troubleshooting are certainly useful. "Tips and Tricks" ... everyone seems to love tricks, a neat way of turning features that are confusing and hard to find into something (looking) cool. :) A page on "Anonymous Aggregate User Behaviour Analytics" with decent explanation: And a simple command to opt-out at the end feels neat. Here is an interesting comparison: https://www.slant.co/versus/1588/1674/~macports_vs_homebrew
Which is quite interesting to read in combination with the listed numbers of packages. :) And looks like claiming to be easy and have everything is a big thing here. :) The ConsThese are perhaps the most important to address
This sounds like a claim that might not be correct. But the mere fact it appears there might suggest putting some visible statements on the landing page stating the opposite :)
Again, as this seems like what people pay attention to, a visible statement emphasizing the positive sides would help.
The same. Pros from HBBy negation, any Pro mentioned that that does not appear for MacPorts, may land into the Cons.
This is quite surprising to see only for HB. List of advantagesGenerally having such a list of advantages over competitors (with or without mentioning the latter's) always looks good. It seems like HB is good at selling itself, why delivery langs but people don't see it so easily. Links to user testimonialsThis might be a great feature! Like this article: Also, comments are interesting, e.g.:
Here is some opposite opinion: https://apple.stackexchange.com/a/34972/56300
Are these actually true?
Just stunning the kinds of vague superficial conclusions people can put in their "shopping lists". |
|
I would say that thes explanations and testimonials would be really beneficial, but they belongs to the main page, not necessarily to the "here's statistics" page, but just to answer some of your questions (sorry, this is all so long, so it takes time to digest everything and respond).
This is mostly true, and would definitely require explanation. HB does the opposite and excludes everything they can. To some extent they started including stuff they excluded earlier as they later figured out it might be a good idea to include that after all. To some extent I would say this is also one of the reasons why MacPorts can afford to support Tiger, while HB only works on the latest versions. The biggest pain is for example bootstrapping the latest compiler toolchain when you end up with gazillion of clang compilers. That said, HB doesn't know how to even do that (and doesn't care), making it difficult to do a fair comparison.
Sadly very true.
True.
No longer true since 2016. |
|
On Saturday, August 10, 2019, Mojca Miklavec ***@***.***> wrote:
I would say that thes explanations and testimonials would be really
beneficial, but they belongs to the main page, not necessarily to the
"here's statistics" page,
Yes, certainly to the main page, truncated whenever if takes too much space.
but just to answer some of your questions (sorry, this is all so long, so
it takes time to digest everything and respond).
Bad at limiting dependencies
MacPorts has a habit of pulling very specific versions of dependencies for
each package. It downloads a different version of already existing
dependencies even in cases where the existing dependency version would have
worked seamlessly.
This sounds like a claim that might not be correct. But the mere fact it
appears there might suggest putting some visible statements on the landing
page stating the opposite :)
This is mostly true, and would definitely require explanation.
Some of those cases are done on purpose and fully justified. Some are not
wanted, but it would be difficult to work around it without breaking stuff
or without a lot of effort.
Not breaking things might be a very compelling justification :)
The "untruth" in this testimonial is subtle. It mentions superficials while
omits much serious and valid reasons behind. I'd give away .0001% of my
drive to a second copy any day over getting a mess or cryptic errors that
might cost hours searching to fix.
Interestingly, this is exactly what `npm` is doing, that is regarded by
many (incl. myself) as one of the most stable package managers. And even
more interestingly, there is `pnpm` https://github.com/pnpm/pnpm, the
alternative to `npm` that cleverly avoids duplication via caching and
symmlinking, that I personally love to use. However, there are regular
occasions where it breaks and I have to use the official `npm` instead.
HB does the opposite and excludes everything they can. To some extent they
started including stuff they excluded earlier as they later figured out it
might be a good idea to include that after all. To some extent I would say
this is also one of the reasons why MacPorts can afford to support Tiger,
while HB only works on the latest versions.
It was already hard to get working from the beginning. Took me several
iterations of searching, posting, replying to get the "right" version of
ruby, then to get it actually recognized. I suppose it is designed to work
out-of-the-box only for whatever they regard as "regular users", with
little regard for others. Which is ok for a niche FOSS project, but imho
NOT ok for a major package manager aiming to play a key role with few
alternatives.
The biggest pain is for example bootstrapping the latest compiler
toolchain when you end up with gazillion of clang compilers. That said, HB
doesn't know how to even do that (and doesn't care), making it difficult to
do a fair comparison.
That is a very good point to mention even on the home page to some extent.
With invitation to contribute for anyone who doesn't like it that way :)
Reminds me the joke https://suckless.org/sucks/:
Clang <http://clang.llvm.org/> is written in C++. If you don't believe that it sucks, try to build clang by hand.
HB is all Ruby whereas MacPorts, and its package formulae, are written in
TCL which is....not exactly a popular scripting language.
Sadly very true.
A niche language feels like a minus indeed, which selection would have had
its reasons at the time I presume. Not that moving over to ruby might be a
big plus :)
http://harmful.cat-v.org/software/ruby/
(A joke of course, that may have parts of joke :))
And how do you find this:
https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_beta_5_release_notes
Scripting language runtimes such as Python, Ruby, and Perl are included
in macOS for compatibility with legacy software. Future versions of macOS
won’t include scripting language runtimes by default, and might require you
to install additional packages.
That said its pretty damn simple to create your own portfile.
True.
It's easy to write and maintain Portfiles, and we have tons of pull
requests for those, but the bus factor of base developers is alarmingly low
and that might become more and more of a serious problem in the future
unless we recruit new people, which is not the most trivial task either.
That is always true of course and is a long subject.
I imagine some kind of collaboration with HB (instead of competition) might
help here, and would certainly benefit the end users.
HB is based around GitHub & thus seems a lot more welcoming to new
contributors whereas MacPorts hosts its own SVN repository somewhere I
think - which basically reflects the different ages of both projects I
suppose.
No longer true since 2016.
That is another problem -- things get mentioned that are not true anymore. :(
… —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#51?email_source=notifications&email_token=AATFSKK7RZ7HESDMNTWR2ZTQDXZ2JA5CNFSM4IHMXV6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD377JIA#issuecomment-520090784>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AATFSKPKM7MU23DZ53LMNSLQDXZ2JANCNFSM4IHMXV6A>
.
|
|
@dmitriz: would you be willing to take another look at http://macports.silentfox.tech/ (the URL might change soon) and open a new ticket or tickets with whatever you still feel would be nice to change? |
Here is my user feedback on the web app version located at http://ec2-52-34-234-111.us-west-2.compute.amazonaws.co
as requested by @mojca on the MacPorts mailing list.
Disclaimer.
I am an old Mac OSX user but am very new to MacPorts. I have been using Homebrew for many years. However, running OSX 10.8.5 that is old by now, I began facing increasing number of broken installations with Homebrew, to the point that it eventually stopped working. So I looked around and discovered MacPorts that thankfully worked wonderfully on my old OS. Having dealt with typical unpredictable behavior of Homebrew, I have found MacPorts pleasantly solid and stable.
There was only one exception that led me to post this question: https://stackoverflow.com/questions/57162325/macports-error-clang-4-0-has-been-replaced-by-clang-8-0-please-install-that/,
and then on the mailing list
https://trac.macports.org/wiki/MailingLists,
where I received very quick help that enable me to find a solution
that I subsequently wrote: https://stackoverflow.com/a/57212770/1614973
Given such positive experience and so much help received, I would like to give back by posting this feedback.
Browser setup
I am viewing the app on my by now very old Chrome 49.0.2623.112 with developer console open to view the app statistics and responsiveness to browser width change.
Landing page
The initial page http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/ loads instantly and it is satisfying to see no console errors unlike I observe with many other webpages. In the Network console I see only 9 requests of total size 3.8KB, that I find phenomenal in the world of massively bloated webpages. Compliments!
Responsiveness
The page is nicely responsive to browser width changes till some very narrow vertical window, the range should more than cover all imaginable browser setups.
Menu
The menu is simple and clean with no possible confusing or ambiguity, which is the main point.
Search Widget
Again clean and simple. One small remark: since menu and other items have all words capitalized, it may be consistent to similarly format the labels:
Top Installations
It is always nice to see the top requested ports, while the numbers feel rather small.
I see from @mojca email that users can explicitly opt-in to statistics submission. If only these users are counted, that should explain the small numbers, in which case, perhaps a clarification would be suitable:
With possible explanation page linked from
opted-in.Of course, it would be even more interesting to view the number of all installations, not only from the opted-in users.
The list currently only contains 5 ports, which can perhaps be increased to 10 (the usual number used for top searches).
Browse by Category
The list of categories looks more like keywords that are often short with unclear meaning, at least for new users.
However, there is a lot of space left to the right, that can be filled with some useful description about what is actually contained in each category.
Also numbers of ports in each category would be helpful to display.
Footer?
There seems to be no footer right now, that would be a helpful feature.
I always find it very convenient to see all the external links from the page collected again in the footer.
Also I imagine, there will be some credits and information about the people behind the project.
The Search
It is certainly very nice to have separately search by name and description.
Some of the description I find rather short, e.g. "circuit-drawing program" is the same description for both
xcircuitandxcircuit-devel, where the latter feels like Developer version that could be briefly indicated in the description.Of course, this is more a feedback for the descriptions rather than the app that pulls these from outside.
One thing missing that I find important would be to update the URL with the search keywords. That way people can easily pass search links in emails or forums.
Another thing missing is the number of search results that could be displayed e.g. in parens:
This would be especially helpful, when not all results fit into the page.
Also at the end I imagine they can be a "More results" button.
The "Cancel Search" button label is in red, which feels a bit aggressive on the eyes.
I would avoid red or any unusual color and use plain black instead. There is only one button that can't be missed, so there is no need to attract more attention via colors.
There seems to be a difference in finding search results for both searches.
Search by port-name seems to allow the keyword to appear anywhere inside the name,
while in the search by description, the keyword must appear as exact word.
This is what I guessed myself experimentally, which can be confusing and might be worth making explicit:
In addition, another search by name with string appearing at the beginning
could be helpful.
Port Description Page
Again, very pleasant to see instantly loading pages with tiny footprint of < 30KB of < 20 requests in total, no bloat.
Also keeping the same menu and search window is nice.
Name/Description window
Clean and well done. The only remark about the "view in Github" button,
that would perhaps be even better to theme with Github's own colors,
i.e. white on black, maybe even with Github's logo,
where on smaller screens just the logo will be enough.
Port Health
This actually looks like the version list, so title "Versions" instead might be less confusing:
The current title "Port Health" is somewhat confusing but also unnecessary due to clear difference in colors and the links attached, where people can get more information.
Also here the last version label is not clickable, which is confusing:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/bzip2/?tab=summary
If that version is not functional and there isn't even a link to it, why even mention it?
Summary Page
I am looking at this page:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/ircii/?tab=summary
The "version" looks confusing:
Is this the last update date rather than version?
If yes, maybe change to date and format as date:
This is, of course, sad but very useful to know:
This one is confusing:
What is "Closed Maintainer"?
Variants page
Clicking on "universal" next to "Variants" delivers over 8k results!
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/ports/variant/universal
Really so many? Most names and descriptions don't seem to be related to
universalthough.The search window here is confusing.
It feels puzzling that I cannot move cursor over the window text
Search Ports with variant 'univeral'Another puzzling thing, this kind of search is not discoverable from the main page.
I did not know this was even available.
As a suggestion maybe add some dedicated links to these pages?
For instance, when searching for
ircii, the additional linkcan appear right below the search.
Clicking on that would lead to that same search in window,
where the search text should probably be made editable
consistently with other search windows.
But now I see the helpful information about the search,
that seems to be missing from the regular search:
along with the pagination buttons.
Pagination
I got curious due to so many results and their order.
And indeed, on page 4 something strange happens:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/ports/variant/universal?page=4
The first half of the page has ports ordered alphabetically until
zlib, after which the order becomes "random"??Then it restarts again from
aand then random again further ahead...Category Search
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/ports/category/irc
Similar issues here, cursor is not movable in the search window.
Dependencies
Very nice to know, but what is "lib" and "run" here?
Visually, the dependencies appear one row below that felt like design error, until I checked some other pages, e.g.
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/openssl/?tab=summary
The alignment seems to be the problem here: "Dependency of:" is left-aligned,
while "build" below is right-aligned.
I would display all labels consistently left-aligned,
while the "build" and "lib" can be indented to appear as sub-classifiers.
(Longer) description on the right
This is of course much more useful than the brief description in the search results.
It could be helpful to show at least some of it directly in the search results.
For instance, searching for
ircsiishows two results with tiny description and leaves a lot of empty space. It could be more helpful instead to use that long description to fill in some space left. For instance, make the rows thicker and show that description, possibly truncated if too long, right below the short description, in the same smaller and lighter font.Also it is not clear to me what "Requested Installations:" means.
(Detailed/Installation) Stat(istics)
On the summary page on the right below, it is called "View detailed statistics for openssl". I find the name redundant here, because we are clearly on the page for
openssl. Also it is called "detailed statistics" here, while the tab is labeled"Installation Stats". I think the latter is better as it is more descriptive and precise,
so maybe just use the same label for consistency?
Another issue: When, on the Summary page, I click that link "View detailed statistics for openssl", it sends me to the Stats tab, as I can see from the URL, but the tab itself is not highlighted, which feels inconsistent.
The controls for the Stats are very nice but the number of installations appear the same for all selections starting from 30 days here:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/openssl/?tab=stats&days=30&days_ago=0
Maybe there are too many choices in the selections?
I would probably limit to 3 choices, with the last one being "all times"
rather than 1 year, which feels random.
The second control "starting from" is less useful and returns empty results
for starting from 90 days ago and above. Which is also incorrect,
because "previous 365 days starting 180 days ago" should certainly include
"previous 365 days starting 30 days ago".
Here I am not even sure what is the use of that second classifier
and making things simpler by keeping only the first selection with 3 choices
would likely suffice for most users (at least for me).
Again, it is not clear what "Requested installations" mean.
"Most installed version" is interested to know, but again, are these all users or only those who opted-in?
From the OS versions, it is a pleasure to see some older OSX versions installed that must be then generously supported. This is certainly appreciated by the users still running these systems for whatever reasons.
I found however surprising the gap with no OS between 10.5 and 10.9 here:
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/port/gcc7/?tab=stats&days=30&days_ago=0
But then I see the number of only 6 installation (for the major port like
gcc7!).Port installations by month
These are always straight lines, which feels weird.
Also only last two months shown.
I presume these would be more useful for the authors.
If I were one, I'd like to see both immediate very short term results,
and ones over very long period if the port is old.
Showing only stat by month here could be less helpful to the new authors
looking for immediate statistics.
I would probably prefer daily statistics for the first moth or two
and then monthly over several years.
Build Information
Impressive amount of details!
Again, perhaps both labels Capitalized for consistency:
The next line "Showing All Builds on All Builders" contains underlined text that can be confused for links. It could be better to used different fonts rather than underline.
The selections displayed are also redundant since the same information
is shown in the selection bars right above.
It is not clear to me the meaning of "Watcher" here, if that could be explained somewhere...
Track Tickets
Quite impressive indeed to see so detailed information.
Certainly helpful to people having problems.
What I find confusing here is the issue list looking formatted as table
with the control tabs right above looking like table field names,
that of course, have nothing in common.
So maybe add some field names for the table?
Like:
Top Menu: All Builds
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/ports/all_builds/
Very nice, as is the option to filter by search!
What is not clear here is the sorting order of the entries.
A really nice and clean feature here would be to have the table field name clickable with arrows up and down, which would make the list ordered by that label increasing or decreasing.
Statistics
http://ec2-52-34-234-111.us-west-2.compute.amazonaws.com/statistics/
Also helpful.
However, what is the meaning of "Users vs Month"?
Also users in plural while month in singular...
Maybe "Users per Month"?
Also the font is too small perhaps.
The table on the right entitled:
"Opt-in for submitting stats by installing the port mpstats-gsoc."
This looks like title, so perhaps larger font, while the table rows below in smaller.
Using the same font as in "Users per Month" would feel consistent.
The title itself maybe rephrase:
This is more of generic description that I think is more helpful.
And then, why not make it a link to the dedicated page
explaining all the details about the opt-ins and what ports to install?
Table rows: not clear to me what is difference between "submissions" and "unique users"
That looks like all pages I could find.
Hope these detailed feedback helps to make it even greater than it is now!
The text was updated successfully, but these errors were encountered: