[Qt-creator] Lost in 4.2
Jason H
jhihn at gmx.com
Thu Dec 1 21:53:17 CET 2016
Thank you Andre, for putting that much more tactfully. My frustration is not due to anyone on this list, but a more general frustration with modern UIs that lack intuitiveness. It seems that it's assumed tht people will click around and explore the UI, however I claim this is a product of bad design to start with. I spent a lot of time in the 90s and 2000s studying UIs. And in fact I give *a ton* of credit to Qt made making great UIs easily. There was once a process that I used to to go through of UI normalization, which is derived from database normalization (3NF and the like). There were a few common rules that when applied would result in a very clear, intuitive UI. I constantly have to explain these to people graduating with degrees in design. Too concerned with colors, padding and fonts, the usability is overlooked. 6 steps to so something that could happen in 2, and without cluttering the UI.
Anyway, to bring it back to the matter at hand, yes, you are again correct. My conclusion of "buttons" is too specific to engage in a cooperative dialog. I'm open to a variety of UI solutions.
I see it in my mind as:
Build & Run [+] [^] | // (+ = Add Kit, ^ =import icon)
- Platform1 |
--Build |
--Run |
-OR-
Build & Run |
[+ Kit] [Import] | // or move to bottom of Build & Run area, below platform list.
- Platform1 |
--Build |
--Run |
I remain open to alternatives. Like, we could see what other platforms or builds are available, and offer them with an "activate" button.
So while fiddling around some more, it seems this last option is already the case (See attached) There are grayed out options, and when I click on them they get a red exclamation. Neat. Id on't know why this didn't work to begin with? But it does now.
One suggestion is when I click on the Platform, it selects the build child item. It might be useful to display the context menu since I effectively can't do anything with the platform item. But if I right click on the platform, I can disable it (or copy steps). It's be a good way to clue the user into the availability of a context menu.
> Sent: Thursday, December 01, 2016 at 4:07 PM
> From: "André Pönitz" <apoenitz at t-online.de>
> To: "Jason H" <jhihn at gmx.com>
> Cc: "Andre Poenitz" <Andre.Poenitz at qt.io>, qt-creator <qt-creator at qt-project.org>
> Subject: Re: [Qt-creator] Lost in 4.2
>
> On Thu, Dec 01, 2016 at 05:33:08PM +0100, Jason H wrote:
> > > Sent: Thursday, December 01, 2016 at 5:02 PM
> > > From: "Andre Poenitz" <Andre.Poenitz at qt.io>
> > > To: "Mike Jackson" <imikejackson at gmail.com>, "Jason H" <jhihn at gmx.com>
> > > Cc: qt-creator <qt-creator at qt-project.org>
> > > Subject: Re: [Qt-creator] Lost in 4.2
> > >
> > >
> > > Mike Jackson <imikejackson at gmail.com>
> > > > <rant>
> > > > Rule 1: "new" way of doing user interfaces dictates that in no way
> > > > should the UI widgets indicate that they can be clicked, moved or
> > > > interacted with. It is entirely up to the user to simply click all over
> > > > the interface until some hidden menu shows up or something happens.
> > >
> > > This is an old-fashioned, standard context menu on items in a tree view,
> > > a concept that is in use in dozens of places all over of Qt Creator since
> > > the beginning.
> > >
> > > The fact that it *also* reacts to single clicks is a convenience shortcut
> > > for people who are capable of reading documentation or possible
> > > asking politely on the mailing list. Also rather old-school skills.
> >
> >
> > It looks nested, but not a tree to me.
>
> It is a QTreeView. There's a delegate to make the first level of items a
> bit larger and bold. The view is also forced to be always expanded, and
> the expand/collapse markers are suppressed (since they wouldn't serve
> much of a purpose since it's not collapsable...)
>
> The core of this terrible modernization is
>
> void SelectorDelegate::paint(QPainter *painter,
> const QStyleOptionViewItem &option, const QModelIndex &index) const
> {
> auto model = static_cast<const ProjectsModel *>(index.model());
> QStyleOptionViewItem opt = option;
> if (TreeItem *item = model->itemForIndex(index)) {
> switch (item->level()) {
> case 2: {
> QColor col = creatorTheme()->color(Theme::TextColorNormal);
> opt.palette.setColor(QPalette::Text, col);
> opt.font.setBold(true);
> opt.font.setPointSizeF(opt.font.pointSizeF() * 1.2);
> break;
> }
> }
> }
> QStyledItemDelegate::paint(painter, opt, index);
> }
>
> All these *gosh* deviations from a stock QTreeView instance are direct
> responses to explicit requests that were made by users of the features
> during the four(!) months this has been publically accessible to anyone
> who has a strong opinion on how the next release of a piece of software
> should look like.
>
> The change went in intentionally in the very early days of the 4.2
> development branch since it is known and understood that certain
> people are bound to express strong opinions on any kind of UI change,
> warranted or not, etc, etc, to give everybody remotely interested
> the opportunity to comment early, ideally before UI string freeze
> which typically marks the end of UI changes for a release.
>
> > There needs to be buttons.
>
> Let me try to translate this into something that I would consider
> a socially acceptable phrasing of exactly the same idea:
>
> "Hey guys, I really tried, but had a hard time to find out how to get
> a kit active for my project. Can't you add a button or two to make
> the functionality from the context menu more directly accessible?"
>
> My role then would be to respond with something like
>
> "Well, it would make it look more cluttered, but sure, there's
> still some room at the bottom, should we put it there?"
>
> This follows a traditional pattern of human communication, even if it
> looks a bit convoluted, if not nonsensical. It leaves you enough room to
> not spell out what you really mean between your lines, and it leaves me
> enough room to not spell out things I really mean between my lines and
> gives both of us an opportunity to actually solve a problem without
> getting overly agitated or upset.
>
> >I vehemently oppose degradation of usability because it isn't "modern".
>
> You bark at a change that effectively removes several hundred lines
> of custom code implementing a machinery of two (three, actually)
> handcrafted tab bars that were specifically designed to look different
> and modern at the time and was unique not only within Creator, but also
> not present in any other application I am aware of, and that replaces
> aforementioned with a stock 90's treeview with two dozen lines of
> customization on top (also available at the time).
>
> Looks like mankind truly entered the post-factual age.
>
> Andre'
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-12-01 at 3.45.45 PM.png
Type: image/png
Size: 33077 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20161201/31b977cb/attachment.png>
More information about the Qt-creator
mailing list