commons-app
Headers to distinguish where suggestions come from
How about placing small headers to show why suggestions are made? Prototype:
--- Nearby ---
Trafalgar Square
Buckingham Palace
--- Guessed from name ---
Demonstration
Climate change
--- Recent ---
Roti prata
Rendang
When I take a picture, I know already what type of suggestion will be correct. For instance if the last upload was of the same thing, I know I must select everything in "Recent". If I am in a famous place but photographing something unrelated to this place (for instance a vehicle) then I can ignore all "Nearby" suggestions. Etc. Having sections will thus make selection faster.
It could also allow making the suggestions list a bit longer without it feeling too long?
Hm, this sounds like a great suggestion, but I think I will have to pick between this and #70 for the grant proposal, due to the time limitations. Which do you think would be more important?
Difficult choice haha. It does not sound as difficult as anonymization, and will probably be more useful to most people.
How do we want the headers to look like? Should they actually take up slots in the ListView like all the categories, just with the '--' to make it obvious that they are headers?
Is there an easy to use component that provide this? Either a ListView with a special setting, or a child class of ListView, or a totally different component.
I was envisioning something like this, maybe with smaller and less eye-catching headers:
http://stacktips.com/tutorials/android/listview-with-section-header-in-android
Hm. This is turning out to be much more complicated than I expected.
I've tried to apply this tutorial (and other similar ones) to our code, but the main issue is that all the solutions that I've found involve adding the section headers to the ArrayList that is used as the data source in the adapter. So now our data source contains not just CategoryItems but also header items.
This could be workable, but in CategorizationFragment.java most of the existing code assumes that every item in the data source is a Category, and operates on it accordingly. Also most of the existing methods rely on using the index of an element in the ArrayList for category selection, assignment, etc. It feels rather messy to have headers be part of that array, and to have to keep checking for getItemViewType(position) whenever we want to perform any operations on categories? I tried this method anyway at https://github.com/misaochan/apps-android-commons/commits/header-list-2 , but stopped after it became unwieldy.
I wonder if there might be a better way to handle this, given that it is only a UI change, so we probably shouldn't be introducing all these extra elements into the data source?
Is there no way to have each row contain an object, and use this object rather than using the row's index?
On Sun, Nov 6, 2016 at 3:38 PM, Josephine Lim [email protected] wrote:
Hm. This is turning out to be much more complicated than I expected.
I've tried to apply this tutorial (and other similar ones) to our code, but the main issue is that all the solutions that I've found involve adding the section headers to the ArrayList that is used as the data source in the adapter. So now our data source contains not just CategoryItems but also header items.
This could be workable, but in CategorizationFragment.java most of the existing code assumes that every item in the data source is a Category, and operates on it accordingly. Also most of the existing methods rely on using the index of an element in the ArrayList for category selection, assignment, etc. It feels rather messy to have headers be part of that array, and to have to keep checking for getItemViewType(position) whenever we want to perform any operations on categories? I tried this method anyway at https://github.com/misaochan/ apps-android-commons/commits/header-list-2 , but stopped after it became unwieldy.
I wonder if there might be a better way to handle this, given that it is only a UI change, so we probably shouldn't be introducing all these extra elements into the data source?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/76#issuecomment-258663552, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBvfAg7df6HaWkg-KFUwW1OdqsnFsks5q7XYDgaJpZM4HmH_N .
I'm not sure, but it would involve an almost complete refactor of CategorizationFragment I think (and also the associated Category, etc classes).
Alternatively, I was thinking of trying a 3rd party library: https://github.com/commonsguy/cwac-merge or https://github.com/commonsguy/cwac-sacklist
The 3rd party libraries I mentioned are on a Apache 2.0 license. Should be okay to include them, right?
The 3rd party library works (as seen in https://github.com/misaochan/apps-android-commons/tree/header-list-cwac-merge , headers are produced for GPS, recent, and title cats), but further issues have been discovered along the way.
The main issue is that in order to get this to work, I have needed to create a separate adapter for the empty search field (which displays automatically-generated GPS, recent, and title cats along with their headers), and for the non-empty search field (which displays the results of a manual category search with no headers).
In the app currently, selected categories are aggregated and displayed at the top of the list, from any type of category suggestion (manual or automatic). This is really useful and something I don't want to lose. But with two separate adapters, I can't seem to get this to happen anymore - selected categories remain selected but are only displayed in their respective adapter (automatic cats that are selected only display when search field is empty, manual cats only display when search field is not empty).
At this stage I think the amount of work needed for me to complete this task is exceeding the benefits that it would bring (headers would be really nice but I don't think it is a dealbreaker for most users). It's entirely possible that I'm missing something simple, so I will leave this issue and my associated branch open, but will move on to the next task for now.
Would you mind posting a screenshot of what it looks like with header-list-cwac-merge ? Thanks!
On Mon, Nov 14, 2016 at 2:51 PM, Josephine Lim [email protected] wrote:
The 3rd party library works (as seen in https://github.com/misaochan/ apps-android-commons/tree/header-list-cwac-merge , headers are produced for GPS, recent, and title cats), but further issues have been discovered along the way.
The main issue is that in order to get this to work, I have needed to create a separate adapter for the empty search field (which displays automatically-generated GPS, recent, and title cats along with their headers), and for the non-empty search field (which displays the results of a manual category search with no headers).
In the app currently, selected categories are aggregated and displayed at the top of the list, from any type of category suggestion (manual or automatic). This is really useful and something I don't want to lose. But with two separate adapters, I can't seem to get this to happen anymore - selected categories remain selected but are only displayed in their respective adapter (automatic cats that are selected only display when search field is empty, manual cats only display when search field is not empty).
At this stage I think the amount of work needed for me to complete this task is exceeding the benefits that it would bring (headers would be really nice but I don't think it is a dealbreaker for most users). It's entirely possible that I'm missing something simple, so I will leave this issue and my associated branch open, but will move on to the next task for now.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/commons-app/apps-android-commons/issues/76#issuecomment-260253875, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGFBgBwj5F_QtmXxRPiCSh23JlFzTfKks5q9_bdgaJpZM4HmH_N .
Sure. A few things to note first:
Note 1: I hadn't hooked it up to the filterYears() method yet, so years are still being displayed Note 2: The items ticked in the manual categories were selected after searching for them. That was done before taking the SSes of the automatic category selections.
This is of the automatic categories:
Scrolling further down:
And further:
And this is of the manual categories:
This looks like a superb idea, and the screenshots above are really helpful. Is this still something that needs to be implemented?
Chris.
Could we add this to a target milestone, then; it's been open for eight years? It looks like people support it as an idea, so if we have a target release, it may attract volunteers who want to write the code.
Just an idea.
This isn't meant to sound harsh, but it feels like good ideas Luke this, should at least be on the 'To Do' list.
Chris