text and entries smaller?

[Tobida]

I like sleek. Up to now i use QTodoTxt for managing my todo.txt. Compared to QTodoTxT sleek uses a larger font size and much more vertikal space between the entries in a list. Which leads to a worse overview over my (tons of) tasks. Is there an option to reduce the row-height and the font size?

thanks

Tobias

[ransome1]

Hi @Tobida .

I think sleek is being used mainly because it doesn't look and feel like the typical Linux application, loaded with tons of features, of which only a handful is being used in production, and a highly customizable interface. Therefor I don't really intend to tamper at least with font sizes.

Nevertheless I think it can't hurt to have a compact view for power users like you. I think we can achieve this by an option that reduces the height of every entry significantly without messing with the overall look and feel of sleek. Let me see what I can do. I'll get back to you as soon as I have a first draft for that.

[plagasul]

Great application! I came into the issues section to ask for a 'compact' view of the app, precisely. Like those minified lists some music apps can convert into, when you only need to glance at it, not interact with it.

so, +1

[ransome1]

Hi @Tobida, @plagasul.

Shall we adjust our views on how a compact view should look like?

Let's start with a first draft. On the left you see the regular view and on the right a draft where the line margins have been reduced significantly. Would this already ease the work for you on longer lists?

[Tobida]

Let's start with a first draft. On the left you see the regular view and on the right a draft where the line margins have been reduced significantly. Would this already ease the work for you on longer lists?

Great! Yes, would work much better for me. If you add some contexts and projects, you can check, wether the size of the boxes fits well in the smaller lines. Font-size is stoll the same, right?

[ransome1]

Hi @Tobida, that should work too

[Tobida]

Hi @Tobida, that should work too

Hi, fine, that works great.

One more suggestion: In the compact view, reduce the size of the contexts and projects in the filter-tab on the left side also to a smaller size, perhaps to the same size like in the todo-list.

[plagasul]

That is certainly looking good !

For me, one of the main concerns would be window width, it seems there is a minimum width of 800px on my 1920*1080 screen. I can't seem to find the css rule that produces this behaviour though. Every relevant parent seems to have a percentual width. Possibly something on render.js setting the window width ? (not familiar with Electron) ...if you point me where is this established in the js, perhaps I can experiment.

In any case that is much wider than what I'd like to see in a compact view, as I imagine it. I understand you don't really want to cover all possibilities, but as you are asking...

I'd also, perhaps, would try to remove A, B, C... priority headings on a compact view, as the color is perhaps enough (on that view) to communicate that information. Although I wouldn't be surprised if you rule that out as those headings are indeed a big part of the app's visual style.

Finally I still sometimes write on the search bar as if I was going to directly add there a todo element, then remember that is a search bar. So I would not mind that to be moved to the icon sidebar as a magnifying glass icon on a compact view.

Hopefully my oppinion is of any help to you.

Thanks

[ransome1]

Hi @Tobida, @plagasul.

The altered line height and also smaller filter tags can now be triggered using the "View" button right below the search bar on the right. A pre release for Linux and Windows can be downloaded here (I don't have access to a Mac at the moment and can't build for MacOS): https://github.com/ransome1/sleek/releases/tag/v0.9.1

Please feel free to give it some testing, if the function works stable.

Best Robin

[ransome1]

@plagasul, the minimum width is set in main.js, where the "mainWindow" constant is declared. sleek doesn't support lesser width so far, because it would imply quite some work on a lot of modules. Plus looking at the current statistics, I can't really say that there a lot of people are using sleek at the minimal width setting.

[ransome1]

@plagasul. Regarding your idea of hiding the priority divider, this is what it would look like:

I think it might still be usable, though I'm not 100% sure if the colored bars alone are informative enough. What's your opinion on this?

[plagasul]

@ransome1 Although order and color is probably enough to communicate priority levels, I think this may be taking too big of a toll on the app's visual identity.

I think I would not go this way unless it was paired with a couple other minification changes aimed towards providing a narrow minified list view. I mean, it may not make a lot of sense to push it there, while keeping a wide window, a big search bar, etc.

I understand what you mean about the difficulty in making the app more narrow, though.

In this sense your previous efforst may be enough in providing a compact view.

This is just my oppinion, would be great to hear more.

Thank you.

[Tobida]

Hi together,

a) I installed 0.9.1 at the moment, works, and is much better for me. I will tell you if i run into functional issues.

b) Hiding priority divider breaks accessability rules. Not everyone is able to distingusih colors. And: I use more then only A-D, but D-Z is grey ... You could improve the hiding provider by using a smaller fontsize for the letter (as big as the normal text but bold) , with a horizontal separator line behind it, or a fill for the whole row.

c) I fell also several times in the trap trying to add new todos by filling the search bar. No idea to improve this.

d) Activating the filter with a width of 800 px leads to a view mainly showing the filter but having only the first ~ 15 letters of the todos in the lost in the side. So i cant see,wether my selected filter will show the items i want to see. Two ideas for improvement:

• Give the Filter-Box 50% of the area.
• let the user move the barrier between filteritems-box and todolist-box (letting the filter items flow in the box).

Thanks!

[ransome1]

@Tobida. Though the filter box has a minimum width, which at a 800px view port is propably already 50% of the viewport, it can be adjusted by the users. Once your cursor hovers over the border between the filter box and the todo table, you should be able to see the cursor change it's icon and from there on be able to adjust the filter box size.

[Tobida]

Once your cursor hovers over the border between the filter box and the todo table, you should be able to see the cursor change it's icon and from there on be able to adjust the filter box size. Ah, ok, works. In my view i have a vertical scrollbar (power user, lots of contexts and projects ;-) ) When I hover over the scrollbar, i get the Button for switching the filter off, but no possibility to move the border left/right. So i thought that this is not implemented. But now with your help i found it - the movable border with the changing cursor icon shows up on the left side of the scrollbar. Which seems to be not intuitive: If you have a window with a scrollbar, the bar to resize the window is normaly on the right side of the scrollbar, IMHO.

Thanks for this hint!

One more thing ;) The "archive" button is hidden in the settings. As it is not a setting but an action, this is the wrong place, in the view of UI-Design. You could pehaps put the button in the border on the left side? And spend the function a shortcut, CTRL + A?

[plagasul]

b) Hiding priority divider breaks accessability rules. Not everyone is able to distingusih colors

Although I am not sure if the whole app follows such rules already, this is a very good point.

[ransome1]

Hi @Tobida.

About the archive function you're right, on the long term we need to find another spot for it as it is not a setting.

But putting it into the left nav bar could lead to frustration for users who don't understand that clicking that icon will literally remove lines from their file and put it into another file. It's not really self-explanatory and that's why I added explanatory text in the settings window and also did not give it a shortcut.

I will think of another solution.

Back to the compact view: I added the minified styling for tablets (if the screen gets smaller than 992 pixel in width) to the compact view also for desktop sized viewports and will now release it as 0.9.1.

If you guys need more adjustments you could fork sleek and adjust the compact view further to your needs and send me PR.

[Tobida]

About the archive function you're right, on the long term we need to find another spot for it as it is not a setting.

But putting it into the left nav bar could lead to frustration for users who don't understand that clicking that icon will literally remove lines from their file and put it into another file. It's not really self-explanatory and that's why I added explanatory text in the settings window and also did not give it a shortcut.

my suggestion shortcut and button on the left would be still the the right solution, with this improvement: If user clicks archive-button/uses shortcut, a textbox shows up with a warning/information, a Ok/Cancel-Button and a checkbox "dont show me this warning again".

but i am derailing the topic, sorry ;)

Back to the compact view: I added the minified styling for tablets (if the screen gets smaller than 992 pixel in width) to the compact view also for desktop sized viewports and will now release it as 0.9.1.

Great!

[plagasul]

After using it for a while I have to say I feel vwery comfortable with the compact view when there are a lot of entries in the list. So, good job, I'd say. And thanks again!