TaskPaper 3.4 Plans, More search and less toolbar

  • More search and less toolbar:

    1. I really like the way that my list looks when I hide the standard toolbar, like a piece of paper!
    2. I want to access search all the time, so currently I can’t hide the toolbar.
    3. My goal in 3.4 is to resolve this problem. Ideas are welcome! :slight_smile:
  • Make it possible to add/remove search tags by clicking on tags in the text. So you can drill down into specific tag combinations. And then pop back out. All without having to type directly into the search field.

  • Allow saving searches outside of your list. You’ll still be able to have list specific searches using @search tag. But I also want to have a place outside of that list where saved searches are stored.

  • More powerful searches, in process of adding count function to resolve.

6 Likes

Can you not move Search to the sidebar and, like Safari, have an ‘Always show (or hide) toolbar in Full Screen’ menubar setting?

Brilliant app, BTW.

I’m playing with different ideas. The biggest issue with that option is it focus showing the sidebar (sometimes I don’t want that either) and it means the search bar isn’t very wide.

Here’s my current idea for removing the toolbar UI while still providing search and focus project navigation:

  1. Search field would expand to fit search text as you type.

  2. Clicking on document title would bring up “Go to Project” navigation menu. (click on little down arrow thingy right after document title would still bring up standard rename/tag document popup)

  3. This UI is replacing the toolbar, there would be no option to show a normal toolbar.

  4. I’m not sure what I will do about other toolbar items such as Toggle Sidebar, Add Item, Tag With. It’s not displayed the above UI, but I think I will add one more generic “Actions” button to the left of the search field. That button will show a popup menu with all the remaining toolbar functionality:

    • Show/Hide Sidebar
    • New Task
    • New Note
    • New Project
    • Tag With…
    • Share With…

This is a mockup at the moment, before I get into the code does anyone have thoughts/concerns/suggestions?

5 Likes

Hi Jesse,

My suggestion for 2. I think your sidebar is already a good project selector!

In some of my TP-files I have 30+ projects so CMD-L (as implemented now) and the dropdown as you suggest, will be long. When you want to select a project on the bottom of the list, you have to scroll down a lot. Therefore I do not use CMD-L not very often (almost never).

I think a fuzzy search in the sidebar will be better.

Workflow 1: Sidebar is visible:

  • cursor is in the project windows
  • press CMD-L
  • sidebar is selected
  • you can use the cursor up/down to select a project
  • press tab to get into the project window

Workflow 2: Sidebar is visible:

  • cursor is in the project windows
  • press CMD-L
  • sidebar is selected
  • start typing
  • use fuzzy search to reduce the list of projects matching the keys (esc will reset of the fuzzy selection)
  • select via mouse or arrow down / up the project
  • press tab to go back to the selected project window

Workflow 3: Sidebar set as NOT visible:

  • cursor is in the project windows
  • press CMD-L
  • sidebar becomes visible and becomes active
  • select the project as above in wf1 or wf2
  • press tab to go back to the project window
  • sidebar hides automatically (because is was not visible before pressing CMD-L

I think in wf3 the sidebar should be an overlay (similar as implemented in the latest version of FoldingText), otherwise the project window will distort to much.

Regards,
Feek

1 Like

Here are two more mockups that I was experimenting with:

They work a bit better with narrow window sizes since the search text doesn’t compete with the title text. These were the mockups that I started with, then think I stared at them to long and so found my previous posted markup appealing and called that my favorite. Now that I’ve stared at that one for a while… these look more appealing again :slight_smile:

Anyway, thoughts welcome!

3 Likes

I like the one titled Untitled 4 the best. I’m not sure I want to really lose the toolbar, but I’m guessing I could adapt easily enough. I’m used to navigating easily enough via command-L. But my list of projects may not be overwhelmingly long such as for @feek.

Have to say that I personally prefer the one with fewer visual edges (and shading transitions) for the eye to be drawn by.

The NewToolBar2.png (upper of the two above) looks cleaner and more work-focused to me.

(but they’re all good)

4 Likes

I agree with you. Cleaner. The gradient toolbar doesn’t go well with the rest of the simple design.

1 Like

Just looking at them, I prefer to first one (NewToolbar2.png).

Hard to tell without actually interacting with it; is there enough visual clue which window is the current window in this case? The chrome of a non-focused window on MacOS loses its gradient and becomes flat when it’s not the front-most window. In the case of NewToolbar2.png, is there enough separation on a screen full of Apps that actually TaskPaper has focus?

Hmm, don’t add a permanent extra search bar below the titlebar, please. It throws off the visual pairing of the sidebar content with the document, and chews up space all the time even when unused. If it’s appearing contextually like most in-app find bars, then fair enough.

If you do go that way, please let us remove it too.

Re the previous mockup with the Search control embedded in the titlebar, I think that’s gimmicky and unnecessary. Generally, all the toolbar stuff is in the menubar too, isn’t it? And toolbars can already be hidden, as part of standard OS X behaviour. I also think that clicking on the document title for in-app functionality is a bad idea, because we’re used to using that area for (1) the path popup, (2) icon proxy dragging, and (3) Versions.

Not sure I see a compelling reason for these changes.

2 Likes

The toolbar that I’m implementing now for the preview is “NewToolbar2.png” above (so white titlebar with search below standard icon/title/status)

It does break that up a bit, but it also makes for a stronger visual pairing of search with the document content, something that I think is also important. In the current UI it’s not clear if search is global or not… moving it above the document content makes it clearer that it’s not I think.

The problem with hiding the search bar is then when you click on a tag there’s no indication that you’ve filtered the view. That’s why I can’t just hide the toolbar in my own copy and have the problem solved. I might still add an option to hide, but I’d really really like a solution that doesn’t require that… that’s my goal with this whole release, make search visible in such a way that I don’t want to hide it myself.

I’d really like to come up with a solution that enabled search to always be visible, especially when search is active. But there might be options to hide (or minimize, maybe just show icon and not placeholder text) when search is empty.

Another thing that this approach will allow is the option to fade away the search and titlebar UI when you are typing in your document, and only show when you move your mouse. (I realize those types of UI’s can be very distracting, and if I add that it will be an option), but I think with this light and minimal titlebar UI it could work better (less visual flash) then most implantations which flash out the standard titlebar.

I think, if I can pull it off in a nice way, there’s a big benefit for an app like TaskPaper to ditch the standard OS X titlebar/toolbar. My problems with the standard toolbar include:

  1. I’m trying to create “text” based interfaces, stripping away as much extra UI as I can. To me a big OS X toolbar above everything has always felt unbalanced compared to the mostly text content of the window below…

  2. This is particularly problematic in a document based app like TaskPaper that needs to show the document icon/title/edit status. Now days most standard OS X apps… Safari, iChat, etc now use compact (hide window title) style toolbars since they don’t need to show that file info. This makes TaskPaper’s toolbar look even bigger relative to the new system standard.

  3. Toolbars fill up with stuff that people rarely use. For example in my Safari I have the default set of toolbar items… (I count 7). I use the back button and URL all the time, other then that the forward button very occasionally. Non of the rest ever–except hitting the sidebar button accidentally once a month or so. But there always there complicating my screen ever so slightly.

  4. In TaskPaper it’s the same thing. I never use any of the toolbar items except for search, but they are always there filling up my window with pixels.

Anyway, this is an experiment. I hope to have it out late this week tryout for real.

4 Likes

All good points. I dig “NewToolbar2.png” the most.

There’s something there. I’m not sure the visual pairing is affected that much for me, but I see how the layout cab affect that visual pairing for some.

2 Likes

It does differentiate less, but I haven’t found it to be a problem in practice… but I need to get the preview done and out to really tell.

1 Like

Hey Jesse,
I love that you’re in there challenging assumptions.

When I look at my two most invaluable “productivity apps”, LaunchBar and nvAlt, there are two other design patterns that could make sense;

  • The one text field to rule them all approach that nvAlt uses, which could introduce some interesting functionality (e.g., depending on the syntax of what you type in the field, you might be searching for something or adding a new entry)

  • The popup text field that LB (and Alfred and even Spotlight) uses, which again could open up possibilities for command line-like functionality based on keywords or symbols.

Anyway, I thought since you were really digging in, there might be something in either one of these two interfaces that might work for you.

Regardless, I’m hacking my lists with TP even more lately and enjoying seeing the product develop. Keep up the good work.

1 Like

This is a solution searching (see what I did there?) for a problem, IMO. There’s nothing wrong and a lot right with the current layout.

I like the gray titlebar. It makes the titlebar stand out from the “working” part of the window.

I want search in the upper right of the title bar. It’s where it is on almost everything I use that has search (Mail, my RSS reader(s), Calendar (whether built-in or Fantastical), iTunes, I could go on for a while). Putting it somewhere else makes me search (see what … never mind) for it. I don’t want to search for it. Because no matter how much I use TP, I’m going to have to search for it every time, because I use ten times as many apps that have it in the upper right as I do TP.

Given that, the icons on the left don’t cost anything. I’m not really committed to them, it’s more like a casual relationship, but this is something we can control. If we want to get rid of them, we hide them. If we don’t, we don’t.

So my answer is, none of the above. Leave it alone. Spend the time on advancing search.

I don’t hate the gray titlebar, it’s the combination of it with the toolbar that looks to big to me. Anyway sometime here I’ll have some previews to show and discuss. But generally for me this is an important problem… something that’s been bothering me since at least the early TaskPaper 2 days in 2009.

It’s true that it’s just visuals, but sometimes visuals, or lack of them, can make a big difference in the feeling that an app gives.

Is there any particular search feature that you are looking for? I’ve implemented a count function for the next release, but beyond that I don’t have any specific search language todos.

Sorry, I wasn’t clear — I meant the other items you mentioned, i.e. having saved searches outside the file, etc.

But, since you asked, having ! be a synonym for “not” would be nice. IOW, “!done” or “! done” would be the same as “not done”.

I honestly don’t do much searching. I only have two files right now, and both are of manageable size.

What I’m struggling with a bit is my “today” list. I haven’t figured out a methodology with TP that is faster (and less distracting) than just writing things down on a piece of paper. But that’s nothing for you to do, that’s something I need to figure out. :slight_smile:

NewToolbar2 with the ‘fade when start typing’ trick added would be fabulously clean!

I immediately dug up two other writing apps I don’t use as much anymore to compare how they pull off the same practice (both a bit clunkier visually than they need to be):

Byword:


and Desk PM:


1 Like

Actually I like the current (3.3.1(217)) style a lot!! I see no good reasons to change that.

I am working in split screen mode, so I don’ see any window chrome. The toolbar looks nice at the topmost position of my screen. (BTW: I have my e-mail client on the left, TP on the right - this works absolutely brilliant for me, as e-mail communication (unfortunately) is a large portion of my job)

Please consider full screen / split screen mode in your decision!

Thank you
Thomas