Make swipe gestures more discoverable

[eisbehr]

Maybe we should add a how-to screen for new users or give some kind of hint in the UI. It's a bit of a "hidden" feature right now.

[ginatrapani]

I don't know... I think swiping across a list item in a touch mobile app is a pretty standard gesture. The iOS app has had it from the get-go.

One thing we could do which seems pretty heavy-handed: when a user taps a task, then taps "Complete" from the menu, we could pop a "Did you know?" dialog with a hint about swipe-to-complete, and "Ok" and "Never show me this again" buttons.

Truthfully, I was considering removing "Complete" from the menu entirely in future releases, so that the swipe gesture is the only way to complete a task.

[eisbehr]

I just know that I didn't remember using it myself, even though I read the change log. Even when you replied on the mailing list just now that we have this feature I was surprised again, completely forgot it already. Maybe that's just me.

[chrisjeffery]

I wouldn't recommend removing the swipe entirely unless it is explicitly taught to the user beforehand. Some users will predict it, but swiping can also be considered as 'delete' as well as 'complete'.

Has there been any discussion of a "first use" interactive tutorial that teaches the user the basics? Sorry if I'm late to the table on that one.

One less heavy handed suggestion I would make would be to do add gesture icons to action menu with an option to hide in the settings. This could be especially effective if gestures were added for update and prioritise as well.

[hunterji]

Please don't remove "Complete". I'd really like to be able to disable the swipe to complete entirely. Maybe it is my phone, maybe it is my incompetent fingers, but I frequently "complete" tasks I didn't mean to when scrolling through the list. Then they get sent to Done.txt (which I like when I intended to mark it complete) and the easiest thing is to recreate them from scratch.

[mpcjanssen]

On my cloned repository I have added swipe to complete as a setting. This should make it a bit more discoverable.

[emilecantin]

In Gmail (and pretty much everywhere), the item you swipe on moves with the swipe. Maybe this would be a good first step in making it more discoverable?

[ginatrapani]

I love the way Gmail handles the swipe, particularly the undo option. Good model for us.

Sent from my mobile On Jun 5, 2013 4:31 PM, "Emile Cantin" notifications@github.com wrote:

In Gmail (and pretty much everywhere), the item you swipe on moves with the swipe. Maybe this would be a good first step in making it more discoverable?

— Reply to this email directly or view it on GitHubhttps://github.com/ginatrapani/todo.txt-touch/issues/282#issuecomment-19016071 .

[chuckbjones]

I may get started on this. I was going to look at how Dash Clock does it in its settings screen since it is open source. I'll try to get the undo working as well, though that may be tricky if auto archiving is turned on. Also, if auto-archiving is turned off, completed items immediately go to the bottom of the list, which could be confusing (though I suppose that won't happen until the list is redrawn, which won't happen until after the Undo button goes away).

It looks like Gmail keeps the Undo button there until you click something else. I guess the easiest thing to do is to wait until then to do the actual completion action. That way, Undo won't have to actually do anything.

[emilecantin]

This would be a bit confusing, in my opinion. I think the best approach would be to mark it as "done" immediately (prepend an 'x' to the line), and move it in the list when the undo button fades away, ideally with an animation so we can see what happens. If auto-archiving is set, we do the actual archiving instead of moving it.

I also don't like the default behavior of removing the priority when marking as done (which makes it a bit less 'undoable'), but I suppose this may be a bit out of scope. (Should I open an issue?)

[chuckbjones]

Yeah, if auto-archiving is enabled, I think it can work the way I described above. Going by the Gmail-style design, the entire row disappears and is replaced by the Undo button. Without auto-archiving, it gets more complicated from a UI standpoint. If you are going to be marking a bunch of tasks complete consecutively, you don't want the list to animate away from its current scroll position.

[chuckbjones]

I also don't like the default behavior of removing the priority when marking as done (which makes it a bit less 'undoable'), but I suppose this may be a bit out of scope. (Should I open an issue?)

I'm not a fan of this either, but it's part of the todo.txt spec and has been forever. So, I don't think it's going to change.

However, if we implement the Undo feature the way I described above, then you won't lose your priority when you Undo a completion.

[emilecantin]

The animation should not scroll the list, just show the item going towards the bottom of the list. Or perhaps we could just make it strikethrough and move it to the bottom only on the next list re-render (like at the next sync).

The way you described above would work and would be quick to implement, but I think it's a bit "quick and dirty". If the app crashes / closes / the phone shuts down while the undo button is still shown, the item won't be deactivated.

[emilecantin]

Quick question: How is removing the priority on completion part of the spec? As I understand it, the only official spec is this one: https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format and it only specifies two rules about completed tasks:

Rule 1: A completed task starts with an x. Rule 2: The date of completion appears directly after the x, separated by a space.

Nowhere is the priority mentioned...

Is there an 'official' spec other than the one I mentioned?

[chuckbjones]

I guess it's not written in the spec, but it is explicitly done in todo.sh: https://github.com/ginatrapani/todo.txt-cli/blob/master/todo.sh#L1103

I thought I remember a discussion on the mailing list about it, but maybe that was all in my head. This is the closest thing I found: http://tech.groups.yahoo.com/group/todotxt/message/423

[ginatrapani]

True, it's not part of the spec, but I always implemented it the the core apps assuming prio was irrelevant after completion.

If we kept prio after completion where would it go? After end date/add date? That's a little weird because it's before add date when a task is incomplete.

Perhaps worth discussing on the mailing list.

[chuckbjones]

The way you described above would work and would be quick to implement, but I think it's a bit "quick and dirty". If the app crashes / closes / the phone shuts down while the undo button is still shown, the item won't be deactivated.

That's a good point. I suppose the best way to go about it is to save the original task in memory (a lastModifiedTask variable, say), then use it both to replace the modified task in todo.txt and to find the task in done.txt for removal. We can potentially use this stored lastModifiedTask for any Undo type operations. It will act like the undo buffer in a text editor.

[emilecantin]

Yeah, that would be a good way to go about this while keeping the current behavior.

[chuckbjones]

Initial version of this is up at https://github.com/chuckbjones/todo.txt-touch/tree/282-swipe-to-dismiss if @intrications or anyone else wants to play with it. It needs a lot more testing, but should be usable. The undo feature probably doesn't work if you have auto archiving enabled, but I haven't tested that yet.

[emilecantin]

Just tried it. Very cool! However, I think some of my tasks are a bit small, especially when they have no date to display. Maybe a minimum height would be appropriate?

[ginatrapani]

Wow, this is awesome! Nice work Chuck.

[intrications]

Looks good. Definitely better with the new 48dp minimum height.

Unfortunately, the swipe-to-dismiss currently still stops the pull-to-refresh. They are both trying to setOnTouchListener to themselves and so obviously both won't work. Maybe there is some way to delegate the touch to both.

[intrications]

Just tried and can actually get both working together quite easily.

[ginatrapani]

Deeply excited about this and pull-to-refresh. Keep in mind the Play Store supports beta-testing now, and I'm interested in trying it. I could pull together a branch with these changes and pull to refresh and invite beta testers to try it out. Let me know when/if the code is ready for that and I'll give it a shot.

[chuckbjones]

My branch is feature complete, so it should be good to go for beta testing. I just need to make sure the unit tests still work and add some new ones for the changes I made to get the undo feature working on archived tasks.

[emilecantin]

I run your branch daily these days, and it's quite cool! The new minimum height really helps.

However, with the latest version I have annoying popups that flash very fast and disappear immediately. They say 'Marking task as done', I think (they disappear too fast to be really sure).

I also had a little bug where assigning a priority to a task while creating it (via the GUI, not by manually writing (A)) would crash the app, but I coud not reproduce it on my latest build.

Great work, and keep up!

[intrications]

I've forked @chuckbjones's branch to add the pull-to-refresh (issue #360) on top of his commits so you can test both working together.

https://github.com/intrications/todo.txt-android/tree/282-swipe-to-dismiss-with-pull-to-refresh

(I realise now that the branch name is a bit long!)

I'm not sure if I've imported the pull-to-refresh library correctly but I tried to copy the way the other libraries had been imported.

The text and progress bar that appears can be easily customized - colours and text.

@ginatrapani How do you plan to do the beta group - using a Google Group or a Google+ community?

[chuckbjones]

I have annoying popups that flash very fast and disappear immediately.

I had originally removed those because I too found them annoying, but then I was able to corrupt the data by swiping a whole bunch of rows really quickly. I'm not sure how it happened because the asynctasks are supposed to be executed sequentially. Adding the progress dialogs back seemed to help, but I can probably find a better way to handle it like disabling swiping while any background task is in progress.

I also had a little bug where assigning a priority to a task while creating it (via the GUI, not by manually writing (A)) would crash the app, but I coud not reproduce it on my latest build.

I can't reproduce this. It's possible that it's related to the change I made to TaskBag.find(), but I don't see how. If it happens again, try to get a stacktrace from logcat.

Great work, and keep up!

Thanks!

[intrications]

I've just updated my pull-to-refresh branch with newly released v0.4 and made a change which enables it to work with ActionBarSherlock on pre-Honeycomb versions.

There is currently a visual glitch on pre-Honeycomb due to the default progress bar style appearing. I'm investigating if this is a problem with the library or something Todo.txt is doing with its styles.

[ginatrapani]

@ginatrapani How do you plan to do the beta group - using a Google Group or a Google+ community?

I think I'm going to use a Google Group instead of Google+. Good old email seems like the easiest interface.

I'm dying to try @intrications branch but I'm having a hell of a time getting all the libraries to play nice together. Continually getting import errors. It looks like PullToRefresh has some actionbarsherlock dependencies in bin (?) that my project isn't seeing. I'll keep trying, but if either of you has figured it out and has time to give me a step by step for configuring the library dependences in Eclipse I'd be grateful.

It looks like that branch is not rebased on the current state of my master (v 1.4). I did that and maybe that's where I'm getting messed up.

[intrications]

I've just pushed a new branch that is rebased on your master:

https://github.com/intrications/todo.txt-android/tree/282-swipe-to-dismiss-with-pull-to-refresh-2

(Tried doing it with the original branch but my git skills aren't good enough yet. I got an error and didn't want to risk losing what I had done).

The libraries are a bit of a mess. I am using Eclipse again at the moment (Android Studio is even more confusing when adding libraries unless using Maven or Gradle).

The PullToRefresh folder has two libraries that need importing. The "library" is the actually PullToRefresh library and the "extras/actionbarsherlock" is to make it work with ActionBarSherlock.

The "extras/actionbarsherlock" library needs to depend on ActionBarSherlock and the PullToRefresh "library".

Then Todo.txt itself needs to depend on the "extras/actionbarsherlock" library which will automatically also depend on ActionBarSherlock and the PullToRefesh "library".

It is confusing! I would recommend using a brand new workspace and import it all together.

I can upload/send you an apk if you can't get it to work but want to test it.

[intrications]

I'm just running through the import in a fresh workspace myself.

Unfortunately two of the library names clash as you try to import them. Both ActionBarSherlock and the "extras/actionbarsherlock" library try to call themselves "actionbarsherlock" so change the name of one of them - it doesn't matter what to.

(I think the library names come from the folder names so I'm not sure how we can avoid this without diverging further from the original libraries making it harder to merge future updates to them.)

The project then compiled fine for me straight away (after adding dropbox.xml), although there are now some errors to do with TaskBagStub in the test project.

[ginatrapani]

I think you can change the project name in project.properties but I wasn't able to sort it out after trying that.

Sent from my mobile On Jun 22, 2013 1:24 PM, "Michael Basil" notifications@github.com wrote:

I'm just running through the import in a fresh workspace myself.

Unfortunately two of the library names clash as you try to import them. Both ActionBarSherlock and the "extras/actionbarsherlock" library try to call themselves "actionbarsherlock" so change the name of one of them - it doesn't matter what to.

(I think the library names come from the folder names so I'm not sure how we can avoid this without diverging further from the original libraries making it harder to merge future updates to them.)

The project then compiled fine for me straight away (after adding dropbox.xml), although there are now some errors to do with TaskBagStub in the test project.

— Reply to this email directly or view it on GitHubhttps://github.com/ginatrapani/todo.txt-android/issues/282#issuecomment-19864112 .

[intrications]

I meant change the name as you import it into Eclipse. When it lists the projects that can be imported, you can change the name by clicking on them.

[ginatrapani]

Ah yes, I see. Starting with a clean workspace and importing fresh worked! I'm compiling this now to test on my own device and distribute as a beta.

I am also getting errors in the test project but I believe that started with @chuckbjones new commits.

The one thing I'd like to make easier/clearer is setting up the project. When I imported fresh, I had to deselect two "MainActivity" projects, and as you said, rename actionbarsherlock to something else (actionbarsherlock-pulltorefresh for me). Screenshot:

I also don't love that actionbarpulltorefresh is called "library" because it's so very generic. I understand the concern about modifying third-party libraries because then we have to rebase our changes on top of any new ones down the road and that can get hairy.

[intrications]

I've just pushed an update that adds .project files which names the libraries better when imported. Also, I removed the samples which were causing the MainActivity imports.

These are only very small changes so should be easy enough to keep on top of them.

[ginatrapani]

Great, thanks @intrications. I've squashed all these commits, made a couple of minor copy tweaks, added another outstanding pull request, and upped the version to a beta in this branch:

https://github.com/ginatrapani/todo.txt-android/tree/beta38

If you join this Google Group:

https://groups.google.com/forum/#!forum/todotxt

You should be able to opt into beta-testing the app here:

https://play.google.com/apps/testing/com.todotxt.todotxttouch

[intrications]

This may not be the best place to ask this, probably a new issue should be opened.

Do you want to change the colour of the PullToRefresh progress bar? I'm not sure how well the Holo blue goes with the green ActionBar. It can easily be changed with android-holo-colors.com?

Also, do you want to change the text? It currently says "Pull to refresh..." and then "Loading...". Possibly "Loading..." should be changed to "Syncing...". Either way, we will need to check/add translations because the original library might not contain all the languages that we need.

[ginatrapani]

Do you want to change the colour of the PullToRefresh progress bar? I'm not sure how well the Holo blue goes with the green ActionBar.

I'm okay with Holo blue for now, it matches the scrollbar and other system UI elements (time, etc).

Also, do you want to change the text? It currently says "Pull to refresh..." and then "Loading...". Possibly "Loading..." should be changed to "Syncing...". Either way, we will need to check/add translations because the original library might not contain all the languages that we need.

Yeah, let's change the text. "Pull to refresh" is fine as is. Let's change "Loading..." to "Syncing with Dropbox..." or maybe just "Syncing...". For comparison's sake, the iOS app says "Syncing with Dropbox now..." when it's syncing.

No worries about translations, I'll take care of that. We've got several new strings and I will submit them for translation to translate.todotxt.com once we finalize 'em.

[emilecantin]

I think that with the addition of the latest third-party libraries, it would be a good time to move to another build system that resolves these automatically, like Maven or Gradle. The project setup would be far simpler.

[ginatrapani]

@emilecantin Want to file a separate issue for that?

@chuckbjones Looks like the only thing left to finish swipe-to-dismiss is tests, there are currently some built errors in the test project. Do you have time to look at that this week?

[chuckbjones]

I got the test project to run and pushed some changes up to my branch on Sunday. I think there are some fundamental problems with how we are using BroadcastReceiver to send messages between different parts of the app, but I don't understand it well enough to know how to fix it, or even if it is something that needs fixing. I should probably create a ticket for looking into that. I don't know if it's causing errors in the app itself, but it was causing issues in the test project, so I wrote some hacks to work around them.

Anyway, the test project should run fine now, and I added a couple of tests for the unarchive function. Hopefully that's good enough.

I do want to find a way to prevent swiping multiple times in quick succession, because that has caused some problems. I want to disable swiping immediately after a swipe and not enable it until the next time the list is refreshed, which will happen after the complete/uncomplete operation finishes. I should be able to take care of that tonight.

[chuckbjones]

OK, I just pushed some changes to my branch that attempts to disable swiping until the current operation has completed. Hopefully we can call this one done now.

[ginatrapani]

Awesome, thanks Chuck!