search

mpcjanssen / simpletask-android

GNU General Public License v3.0
549 stars 128 forks source link

Update to material design #128

Open mpcjanssen opened 10 years ago

alehandrof commented 10 years ago

Are you planning this as a veneer operation or a rethinking of the UI as a whole?

There are current issues (such as this one) that can be be better addressed by tweaking how the user interacts with tasks. It's more efficient to have one operation (edit task, or bulk edit multiple tasks) that allows the users to add/edit/remove lists, tags, etc., rather than have each of these be a different operation.

mpcjanssen commented 10 years ago

Initially just a veneer operation. I am curious what the Material theme brings. Besides that L provides easier list widgets which might make the code simpler.

Maybe later rethink the UI, but before that I will have to see some new material apps to see what material design actually means.

alehandrof commented 10 years ago

Fair enough.

y2kbugger commented 9 years ago

"It's more efficient to have one operation (edit task, or bulk edit multiple tasks) that allows the users to add/edit/remove lists, tags, etc., rather than have each of these be a different operation.?"

I second this, if it doesn't have its own issue yet, it should. This is mainly a concern for new users as we are still settling in to how we want to arrange our lists and tags.

y2kbugger commented 9 years ago

If I have time I am thinking about playing around with streamlining the ui. I'm putting this here partly so that I can remember it, partly so that I can get some other peoples opinions, and partly so that somebody some will do something similar.

My idea: Have just one bulk add/edit interface This will be very similar to the existing "add/edit" text box allowing inserting list/tags at the cursor. Basically I want it to work like this:

  1. Click [@list] or [+Tag] button
  2. Keyboard gets hidden.
  3. The line you were editing before you clicked [+Tag] button gets shown at the top with the cursor itself continuing to blink. Maybe show one line above and below slightly faded.
  4. The checkboxes act as tri-state boxes, allowing you to add or remove tags from all of the tasks currently being edited. To the left of the tag there will be a little insert button that lets you insert into just the one line right at the cursor.
@actions line currently containing the cursor >>|
^  tag1                   [ ]
^  tag2                   [x]
^  tag3                   [ ]
^  tag4                   [ ]
^  tag5                   [ ]

this will eliminate the need for the "copy previous" and resolves https://github.com/mpcjanssen/simpletask-android/issues/184 It also eliminates any awkwardness with the enter key acting in a nonstandard way.

some things to think about how add this features without making it harder to make a grocery list:

  1. If editing, have checkboxes initialize to a "soft/grey checked" if least one task being edited has that tag.
  2. if all tasks being edited share a tag then initialize those checkboxes to a "hard/black checked"
  3. If the editor was reached by pressing the "Add Task plussign(+)", initialize the checkboxes to a "hard/black check" corresponding to the current filter, similar to how right now it puts the filter in the text box in the app right now.
  4. If a list/tag is hard checked, then new lines get those lists/tags automatically

This is awesome because it allows the editing of group of tasks such as this:

@errands bread
@errands milk
@errands cake
@errands pudding for +mom|<<<cursor

You would have been able to insert the mom tag, and when enter is pressed, the next line would be 

@errands |<<<cursor

Allowing you to continue the main theme of the list uninterrupted by one more specific item

Then at anytime you could "hard check" +grocery because you remembered that you don't want to mix all these items in with you other errands for the day. This would append +grocery to all existing and new lines unless you uncheck it.

One other problem this solves is when changing something from a list to a tag because you want to reorganize. +grocery --> @grocery. The way it works right now is that you have to select all of the tasks twice once to add the new tag and once to remove the list. this can get pretty tedious after a while.

One more thought a side by side view could be really handy. paired with what I wrote here https://github.com/mpcjanssen/simpletask-android/issues/189 it could be really powerful.

@actions line currently containing the cursor >>|
 ^  @agenda        [ ]    ^  bank             [ ]
 ^  @errands       [x]    ^  mall             [ ]
 ^  @projects      [ ]   ------------------------
 ^  @waitingfor    [ ]    ^  paul             [ ]
                          ^  landlord         [ ]
                          ^  doctorO'reilly   [ ]
mpcjanssen commented 9 years ago

Will need some time to review this but one worry is that this will be difficult to use on smaller devices.

y2kbugger commented 9 years ago

I agree, the side by side should either be optional/tablet only

Also it could work by inserting upon tapping the text of the list/tag itself instead of the row of buttons to the left. On Jan 18, 2015 11:17 AM, "Mark Janssen" notifications@github.com wrote:

Will need some time to review this but one worry is that this will be difficult to use on smaller devices.

— Reply to this email directly or view it on GitHub https://github.com/mpcjanssen/simpletask-android/issues/128#issuecomment-70414127 .

smichel17 commented 8 years ago

I am working on a new design (a small but significant set of changes) that will address this issue and a couple of others scattered around the tracker. The design is finished, depending on how much time I have to work on the mockups, it'll be up in the next couple of days.

Related: #182 and #132

smichel17 commented 8 years ago

2016-08-31 edit: I will likely propose larger changes to the editing process, so this comment is out of date.

Done! One note: I don't like some most of the icons here (both the ones I added and a couple of the current ones): some are unclear what they stand for; others are not very distinctive. I used them anyway because I wanted to get this done; If you decide to implement, we can go on a hunt for better icons.

List view

Apologies for these screenshots being so freakin' huge. I will scale them down next time.

listview-draft

listview-optionsopen-draft

Edit view

addtask-oneline

addtask-alllines

@mpcjanssen I have an idea for an animation that would make the transition from list to edit screens much smoother, but would be unique to this application. How comfortable are you coding custom animations? :wink:

y2kbugger commented 8 years ago

List view Please please consider Complete/Uncomplete with a swipe like gmail does. If you are a view where completes are visible, leave it/ resort it if required. Use the exact same undo visual language used by the newest gmail. That way, whether it is disappearing on you or not you always have a chance to catch yourself. Also if done this way it makes sense to hide the Complete Uncomplete in the menu.

Edit view Regarding the shift thing, isn't that what the overflow menu is for. I think this may cause issues by not following the principle of least surprise as well as flowing to different sized screens. I see what you are doing now. So its kinda non standard still. Would longpressing/ upswiping on the text version (top picture) be a better way to unlock. Also another decision here regarding the #182 should tapping mid word(or at the end of a word) put the @ or + at the beginning of the word, or start a new word. I think at the beginning of the word. That way we could quickly tap to put the cursor in the middle of the word and then listify or tagify it.

smichel17 commented 8 years ago

I see what you are doing now. So its kinda non standard still.

Well, the more standard way is simply not to offer the text versions. That was actually my first iteration; the 'done' button replaced the shift button. If people were okay with only starting autocompletion by typing a + or @, then this would be fine, but as you noted in #182, those keys are not very accessible on most keyboards.

I'm happy to think through other solutions, though.

Would longpressing/ upswiping on the text version (top picture) be a better way to unlock.

The thing is, I'm not sure what visual indication a user would have that this functionality is available. Functionality that users don't know about is useless (see also: the filter drawer).

Also another decision here regarding the #182 should tapping mid word(or at the end of a word) put the @ or + at the beginning of the word, or start a new word. I think at the beginning of the word. That way we could quickly tap to put the cursor in the middle of the word and then listify or tagify it.

This seems reasonable.

y2kbugger commented 8 years ago

Well, the more standard way is simply not to offer the text versions. True. Also just noticed that github has a button that merely inserts an "@".

smichel17 commented 8 years ago

For due, threshold, and priority, I expect them to be inserted in a consistent location (IMO, beginning is best) no matter where my cursor is.

For lists and tags, I would really need to test this out to see what's best.

y2kbugger commented 8 years ago

not when you use it in prose my homework is due:2016-04-27

this is even more of a big deal for lists, tags. I think this adds complexity and might not beer the last surprising way to do this. what about old tags. what about those of us who track their lists with git? On Apr 13, 2016 10:00 PM, "smichel17" notifications@github.com wrote:

For due, threshold, and priority, I expect them to be inserted in a consistent location (IMO, beginning is best) no matter where my cursor is.

For lists and tags, I would really need to test this out to see what's best.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mpcjanssen/simpletask-android/issues/128#issuecomment-209721262

smichel17 commented 8 years ago

not when you use it in prose

okay, fair.

I think to start, perhaps the best way would be so simply insert the chars at cursor for dates, lists, and tags. I imagine this is by far the easiest to implement, and it would give us a chance to play around with it and figure out edge cases. It's also safe to do: while it's better to correctly guess what the user wants than not guessing, not guessing is better than guessing wrong.

The one exception being: if the cursor is at the end of a line and does not follow a space, we should absolutely insert a space and then the text.

y2kbugger commented 8 years ago

I agree to that point:

You don't want it to start mangling text when people try to copy and paste, or type an email address using thye button, for example of an edgecase.

One of my biggest frustrations with windows is when it does things like select extra characters because "of course people only want to select whole words, let's make a feature" ggrrrrr M$ does NOT know what I want!

On Thu, Apr 14, 2016 at 12:05 PM, smichel17 notifications@github.com wrote:

not when you use it in prose

okay, fair.

I think to start, perhaps the best way would be so simply insert the chars at cursor for dates, lists, and tags. I imagine this is by far the easiest to implement, and it would give us a chance to play around with it and figure out edge cases. It's also safe to do: while it's better to correctly guess what the user wants than not guessing, not guessing is better than guessing wrong.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mpcjanssen/simpletask-android/issues/128#issuecomment-210020995

smichel17 commented 8 years ago

@y2kbugger Two things about swiping:

  1. Swipe is an archive action. If swiping on tasks is added it should be swipe to complete-and-archive. This would probably go along with removing the archive on completion setting.
  2. Unfortunately, adding swipe functionality conflicts with #411. If you had to choose between quick access to filter settings a-la #411 and swipe to complete-and-archive, what would you choose? I will think about this and see if I can rework #411 to be compatible with swipe to archive, but I am not hopeful.
mpcjanssen commented 8 years ago

@y2kbugger @smichel17 I personally dislike swipe actions if the app has a sidebar. I will always modify something while trying to open the sidebar. I find quick filter access much more important than swiping actions, so swiping is not likely to be added any time soon.

smichel17 commented 8 years ago

FWIW I think swiping is very overrated. I think it's pretty much only a good idea if the entire app is designed around swiping as a primary action, which this one is not (nor should it be).

smichel17 commented 8 years ago

I have a design I like to replace the bottom toolbar. Mockups at some point.

@mpcjanssen isn't going to like it because it's a bit of UI work with a little bit of non-standard stuff in there, but I think it won't be too bad, and will really be a huge improvement. It will also completely replace the AddTask activity for editing tasks, so we can gear the AddTask activity towards adding new tasks only (eg, convert the buttons to insert text at the cursor instead of modifying existing task.an

smichel17 commented 8 years ago

It will not be that bad. We need to switch to a CoordinatorLayout and AppBarLayout but after figuring out how they work it should not be that complicated.