Feedback on Komodo IDE v9 UI

Discussions
1

I’ve been using the Komodo IDEv9 early releases almost exclusively for the past couple months and would like to offer the following feedback on items in the new UI that feel like they need a bit of polish. Hopefully, the Komodo team will take this as constructive criticism and can address these as v9 continues to evolve. All of this feedback is based on my use of v9 on Mac OS X 10.9.x and 10.10, so some of the items I will offer feedback on may be specific to that platform. I’ve included 3 screenshots and have referenced them where appropriate below. And in the interest of fairness, there is much about the new UI that I like.

For background, I’ve used Komodo Edit or IDE as my day-in/day-out editor professionally and personally for Web application development and most other plain-text editing since the v4 days. For the past 6+ years, I’ve worked almost exclusively with Komodo on Mac OS X with a bit of work here and there on Linux systems.

  1. New icons are slow: Move to a folder with hundreds or thousands of files and it can take a significant period of time for the icons to be drawn in the “Places” panel. One example of this is any icon library; we use the Fugue icons, among others, in several of our projects and it can be painful to watch the icons being drawn and labeled.
  2. New icons are inconsistently spaced: Compare the vertical spacing of the new icons in the “Places” panel with those of “Open Files” panel. Visually, the spacing of the “Places” panel is more appealing with a slight gap between the icons. To be fair, as shown in the screenshot of v8, the spacing there is also inconsistent but the slightly smaller icons in v8 do leave a small gap between them in the “Open Files” panel rather than having the smashed against each other there as v9 currently does. (Screenshots 1, 2)
  3. New icons are inconsistently sized: Compare the size of the new icons in either the Places or Open Files panels with those of the file type panel available in the status bar at the bottom of the editor. I would vote for making the file type panel consistent with the spacing and sizing of the Places panel. Compare that panel in v9 to it’s implementation in v8, and the v9 implementation looks like it still needs some work. (Screenshots 1, 2)
  4. New icons are inconsistently colored and labeled: Compare the icon colors and labels applied to CFM files in the v9 screenshot. Grey with “TXT” in the file type panel (even though the Komodo extension registers “.cfm” as the primary file extension), but an interesting shade of brown (?) for the editor tab and the “Open Files” panel, along with the “CFM” label on the icon. Ideally, all of these would be consistently colored and labeled. In addition, all registered file extensions for a given file type would be treated consistently in terms of colors and labeled appropriately. (Screenshot 1)
  5. Spacing of icon, filename, and close icon on editor tabs should be addressed: The close icon is smashed up against the filename, and would benefit visually from some horizontal spacing. Compare that with the spacing in v8. Although I almost never have editor tabs shown, and rely on the “Open Files” panel instead, this is something I noticed and wanted to raise. (Screenshots 1, 2)
  6. The highlight color on the popup that provides attribute support for HTML tags and CSS attributes (for example) would benefit from some additional contrast with the background of the panel and/or the color of the text for each entry. I switch between a light and a dark color scheme depending on light and setting (color schemes tweaked from the Solarized palette), and in both cases – but particularly with the dark panel used in the darker color scheme – it is very difficult to see at a glance which is the currently highlighted entry from the list. I find myself moving the selection up and down to try to make sure I have the right attribute highlighted. (Screenshot 3)
  7. The combination of colors, shadows, etc., used in the status bar are simply not as clear or legible as the status bar in versions prior to v9. (Screenshot 1)

Screenshot 1:

Screenshot 2:

Screenshot 3:

–
/ron

2

Nathan already know about 2 and 3 - I’m created topic with same problem.

3

A bit more: note the “Command Output” panel when building an extension. It seems to be confused in its colors (or perhaps they just don’t make sense to me, given the color scheme?), and it seems to overlap the right panel.

4

Before I respond to your individual concerns let me first thank you for taking the time to write all this down! I really appreciate it. That said, note that UI polish is still in progress, particularly for OSX and Windows.

  1. Could you provide your hardware specs? Also if you could provide a screen recording this would be much appreciated! For language icons in particular we might simply provide pre-cached icons so you won’t need to generate these all yourself the first time.
    That said, a folder with “hundreds of thousands of files” is going to be loading slow no matter what we do, Komodo adds a lot of functionality to your Places pane (version control, file status, icons, etc). If you intend to use Komodo with insanely large projects you will probably want to disable some of these features. In particular you can disable the icons by clicking the cog/gear icon at the top right of the Places pane.

  2. Yep I’m aware, this is still being polished. Created a bug for it here: https://bugs.activestate.com/show_bug.cgi?id=105931

  3. I assume you are speaking of the language selector popup? This was a consious decision in an effort to make language selection easier (larger icons are easier to identify). I don’t think consistency is a big factor here, it’s a completely different context.

  4. This is because of file association and the fact that in your language popup the icon is being calculated from the language itself whereas in your Places / Tabs it uses the file extension for reference. Obviously this should be fixed and I’ll certainly be looking into it. Bug here: https://bugs.activestate.com/show_bug.cgi?id=105930

  5. See 2

  6. Thanks, this is why we need feedback - the contrast ratio on my screen is much higher so it wasnt an issue for me. Could you give me the color scheme that you used? Bug here: https://bugs.activestate.com/show_bug.cgi?id=105932

  7. OSX bug, will fix this.

  8. (command output) Bug here: http://community.komodoide.com/uploads/default/413/66eb1db1229d8887.png

Again thanks a bunch for taking the time to write all this down! Feel free to report obvious bugs directly to the bug tracker: https://bugs.activestate.com/enter_bug.cgi?product=Komodo

5

@nathanr I’m never short of opinions (as I’m sure anyone who knows me will readily agree); I just usually try to be judicious in sharing them. :slight_smile:

RE 1: I think you may have misread what I wrote on this one; it is “… hundreds OR thousands…” rather than “… hundreds OF thousands…”. I agree that if I have a project with folders containing hundreds of thousands of files, I probably should expect a bit of sluggishness at best. That would, as you noted, be crazy. My primary development system where I see this is a MacBook Pro with a 2.5 GHz quad i7, 8G of 1333 MHz DDR3 RAM, and a solid state drive. These folders are local (e.g., not from a network drive). I do have version control disabled in Komodo. I will try to get a screen capture showing what happens when I browse into one of these folders as Komodo paints the icons.

RE 3: I will follow up with more thoughts on this specifically, and on the file icons in general, but I haven’t pulled all of my thoughts on those together into something cohesive yet. Need a bit of time and a couple more cups of coffee to sort out my thinking there.

RE 6: I will add my color scheme (or a link to it) to the bug report.

6

RE the language selector and the file icons in Komodo v9, in general: Drafting my original feedback and your response regarding the language selector from the status bar pushed me to do both some thinking to try to organize this and a bit more poking in configuring this new version of Komodo (both good things, I think). I’ve tried to pull my thoughts on the language menu and the file icons together into something that makes some sense. I recognize that this is heavily loaded with my own opinions and based heavily on how I use and configure Komodo, so please take this in that light.

I’m going to say right up front that I am not a fan of the colored-block icons used in v9. They are mostly just visual noise to me. Part of that may be because I don’t understand the approach to assigning colors to specific file types and/or because the current assignment of colors to file types doesn’t offer me any meaningful visual cues about the types of files. I’ve looked a little at this, and only the red assigned to Ruby files seems to have some sort of logic to it (again, to me). I think part of this, too, is that other than the icons used for CoffeeScript, HTML5 and Python files, the current approach doesn’t really seem to be an “icon” to me: they are just colored blocks with white text based on file type or file extension, depending on the context. There’s nothing there visual for me – given that the colors don’t provide that cue – to make a mental association of icon to file type. Labeling the icon with text to denote file type feels to me like it flies in the face of the intent of an “icon” if I have to actually read it to figure out what it is, and the size of the text used to label the icons makes that (reading the label) a challenge. That’s true even on the language selector from the status bar with the larger icons: the stretched aspect ratios and the way they are labeled makes those difficult to read (some more than others; looking at you: node, less, JSON, in particular). The language selector in v8 uses what I would consider “real” icons and does not suffer this same problem. Compare the screenshots of the v8 and v9 language selectors.

Your comment about turning off icons in the Places panel was an interesting one; I had never noticed the ability to do that before, and – given my feeling about the new icons and the sluggishness I see on folders with large numbers of files – I will almost certainly go that route immediately. I wish I could also turn off icons in the Open Files panel, as well. I almost always have the Open Files panel open, and almost always have it configured to group files by type… so all of the files in a group have identical colored blocks, so those icons – being identical – again do nothing for me to differentiate files. I recognize that this may be specific to the way I group entries in the Open Files panel, but where the icons currently don’t do much for me, I’m reasonably sure that I would also prefer no icons there as well even if I grouped them differently in that panel. The organization of the code in folders in most of my projects is also grouping by file type, and so most folders include all (or almost all) files of a single type… and thus also a single colored icon, so I’m working by file name anyway. (And even though I rarely have editor tabs showing, I’d love to be able to disable the showing of icons there, as well, for consistency and for all the same reasons I would tend to turn them off in other places.)

I’m not sure your take on the larger icons in the language selector makes sense to me. That same approach has not been applied to the other selectors/navigators available through the status bar where file type icons are shown, and I far prefer the layout and appearance of them to the current implementation of the language selector (see screenshot). I do use the navigator from the status bar a fair amount and I don’t find that its usability suffers at all based on the size and spacing of the entries, even given that it often contains far more entries. Further, I would argue that being able to quickly and efficiently navigate that UI element and make the right selection reliably is more important from the standpoint of how many interactions are required to backtrack if I choose incorrectly.

Not specifically related to the icons, but related to the subject of UI consistency: I also noticed that the fonts, etc., on the file structure navigator (I’m sure that’s not what it is really called) are different even from the others I’ve touched on here… so we have at least three different approaches taken to the various selectors available from the status bar. Visually, I’d like to see much more consistency in fonts, font sizing, icons, and icon sizing across all of these. Of the three approaches, the language selector is the worst (least attractive and most different). (See screenshot)

@nathanr: Quite a lot here to sift through, I realize, but that’s the risk you take in asking for opinions and feedback. Hopefully, this will be of some use to you.

Screenshots:





7

Re colored icons - The idea behind this is that the color itself becomes the identifier. Also all major languages have their own dedicated icons (ie they are hand-designed), secondary languages have their icon generated on-demand based on hashing (to guarantee that the color is at least somewhat unique). As always not everyone will like the UI changes, at the end of the day we can’t please everyone. I’ll likely still play around with this but I don’t see them changing too much. I’d be open to reviewing suggestions (in the form of mockups).

Re turning off icons - I might implement this UI-wide, rather than have it be specific to Places. Note that you can use Stylish to manually disable these icons. It does indeed sound like the organization of your files make icons redundant altogether, in which case no design would be likely to please you as you tend not to use icons for visual reference at all.

Re large icons - it is precisely with “quick navigation” in mind that they are slightly larger. Note they are 24px inostead of 16px. I’ll keep your feedback in mind but I’d like to hear from more people before considering reverting back to 16px.

Re font consistency - hmm I’m not sure why this would be the case, I don’t recall setting any fonts, thats all handled on the OS level. Will verify what you said though. As for font SIZE - this is an annoyance of mine as well, I need to find the root cause of this problem, probably some weird moz-appearance behaviour somewhere that will be hard to override.

8

RE colored icons: I understand the idea; just saying that color alone does not seem to work for me in this context as well as image-based icons. I have no idea where I fall on that spectrum. And you are absolutely right: nothing you do here will work for everyone.

RE turning off icons: The ability to do this on a more global basis /may/ make sense, but if I had to pick one area that I use on a regular basis where I would want to retain that area’s approach to icons it would be the Toolbox panel: I appreciate the ability to assign icons I choose to entries there, and I do take advantage of that. Although I would turn off the use of the current file-type icon approach throughout the most of rest of the UI I use on a regular basis if I could (with Places and Open Files being the first two, and editor tabs a distant third), losing icons on the Toolbox entries would represent a big loss in usability. Where the Toolbox icons aren’t really the file-type icons we’ve been discussing, perhaps those would not be part of your global approach? I do like the idea of being able to turn off the use of the file-type icons in configuring the app and it’s UI without having to resort to a Stylish-sort of approach, and that would definitely address my “visual noise” and “they don’t work for me” concerns. (Again, my two cents.)

I will try to follow up later today with a screen-capture showing the sluggishness I’ve seen with the file icons in folders with lots of entries.

Thanks again for your interaction here, and giving us access to these early builds to play with and offer feedback on.

9

@nathanr I finally have a screen-capture of the sluggishness with the icons in folders with lots of icons; see http://www.we3geeks.org/files/k9-imageicons.mov

In the video, I navigate to one such folder and scroll to the bottom of the folder, then wait for it to catch up, then scroll back up to the top of the folder.

10

Yeah that is unfortunately the way it is with such a huge number of files. Mozilla trees do not pre-render icons that are not visible, so when you scroll down it is rendering those icons as they become visible.

@toddw can we make it retrieve those icons on a timeout (eg. x seconds after you stop scrolling) ? I’m guessing this is pretty difficult, considering its handled by the Mozilla tree elements.

11

I don’t think that’s a performance issue of the mozilla tree widget itself. The mozilla tree widget is optimizing (lazily loading tree styling properties) for these cells, which is all done asynchronously - that’s seems fine to me. You can have millions of tree rows and the mozilla tree will handle that without a performance slowdown.

I’d hazard a guess that any slowdown is coming from Komodo’s overhead in the Places code, either where it creates a file object for every entry in the visible tree and then performs file status checks (file permissions, scc info, …) to populate the tree properties, or perhaps something with the fetching of the icon data for the tree row, or perhaps just overhead of calling Python for all of the tree information.

12

@nathanr I am starting to see some of these get addressed in the latest nightlies, and wanted you to know that I noticed. :smile:

The large icons in the file language selector popup no longer appear to be stretched/squa. I also noticed a change in the highlighting of the popup that provides attribute support for HTML tags and CSS attributes (#6 in my original post); definitely more noticeable in both the light and dark versions of the color scheme I typically use.

13

I have to say - for me - with the icons on I find the colors at best distracting, but with them off I find the pane somehow looks ‘bare’ !

It would be nice to be able to revert to just plain white icons (as in 8.5) for the files as well as completely turning them off for everything.

I know, you can’t please all the people all the time. :smile:

14

I’m seeing the editor tabs stretched waaaay out to fill the entire space. Looks awful, it’s hard to scan, and it’s hard to close multiple tabs quickly. Here, I have two tabs open:

I’m on OSX. This was not an issue on an earlier nightly.

I love the filetype icons.

I hate that when I use the abyss theme, the right-side panel is still white, but has light gray text. Something’s wrong with that.

15

For the first one: [quote=“nathanr, post:11, topic:1242, full:true”]
Yes it’s specific to OSX, as this is how tabs appear to be handled by native OSX apps.
[/quote]

For the second one: file a bug please here https://bugs.activestate.com/enter_bug.cgi?product=Komodo

16

It does look a bit odd on large screens, I’ll have another look at it but that wont be until 9.1. We’re too close to the final version now and this is a subjective issue for the most part.

I just fixed this, should be in tomorrows nightly.