Hi everyone,
Since the Android beta release, we've been getting a lot of feedback about what people want added in. Here's an email listing some of those things, so we know what we've got to focus on.
1. Dark theme! A dark horse... no pun intended. By far the most requested feature. 2. Watchlist. The most requested feature from the editing community. 3. Searching within articles.
Thanks, Dan
On Mon, Jun 9, 2014 at 10:51 AM, Dan Garry dgarry@wikimedia.org wrote: * Dark theme! A dark horse... no pun intended. By far the most requested feature
This is a regression as we've had it before. Dan, do we need anything from the designers to schedule this?
Watchlist. The most requested feature from the editing community.
Very interesting for the power user. Do we think that this would be enough or would users then need diff, revert, etc? Let's interview some users to not just know the "As a ..., I would like to" but the "so that" in this case to find out motivation.
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
--tomasz
Themes is a feature I wonder if we really need. But from a design point of view would be fun to implement. Instapaper does a good job of this. http://iphonesoft.fr/images/appstore/288545208/instapaper.jpg
Watchlist, yes lets do it. We can take a similar approach as mobile web.
Searching within article, this feature has been in the Wikipanion app on iOS for ages. They dont do that good of a job with it as far as the interaction design is concerned but the feature works and is helpful too sometimes when you're looking for a fine-grained search within an article. If we do work on it, we should definitely make it better than what Wikipanion is doing. I have some ideas.
On Mon, Jun 9, 2014 at 11:00 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 10:51 AM, Dan Garry dgarry@wikimedia.org wrote:
- Dark theme! A dark horse... no pun intended. By far the most requested
feature
This is a regression as we've had it before. Dan, do we need anything from the designers to schedule this?
Watchlist. The most requested feature from the editing community.
Very interesting for the power user. Do we think that this would be enough or would users then need diff, revert, etc? Let's interview some users to not just know the "As a ..., I would like to" but the "so that" in this case to find out motivation.
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
--tomasz
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
+1 for themes being fun to implement, and also useful. The Kindle app for Android also does a similar thing as the Instapaper app.
On Mon, Jun 9, 2014 at 2:24 PM, Moiz Syed msyed@wikimedia.org wrote:
Themes is a feature I wonder if we really need. But from a design point of view would be fun to implement. Instapaper does a good job of this. http://iphonesoft.fr/images/appstore/288545208/instapaper.jpg
Watchlist, yes lets do it. We can take a similar approach as mobile web.
Searching within article, this feature has been in the Wikipanion app on iOS for ages. They dont do that good of a job with it as far as the interaction design is concerned but the feature works and is helpful too sometimes when you're looking for a fine-grained search within an article. If we do work on it, we should definitely make it better than what Wikipanion is doing. I have some ideas.
On Mon, Jun 9, 2014 at 11:00 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 10:51 AM, Dan Garry dgarry@wikimedia.org wrote:
- Dark theme! A dark horse... no pun intended. By far the most requested
feature
This is a regression as we've had it before. Dan, do we need anything from the designers to schedule this?
Watchlist. The most requested feature from the editing community.
Very interesting for the power user. Do we think that this would be enough or would users then need diff, revert, etc? Let's interview some users to not just know the "As a ..., I would like to" but the "so that" in this case to find out motivation.
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
--tomasz
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
We had an idea for day (bright) and night (dark) mode for easier reading. It'll be great to create a night mode for easier night reading purposes instead of a just for fun feature. I've done quite alot of work around this area, I'll be happy to chime in whenever appropriate.
On Mon, Jun 9, 2014 at 11:24 AM, Moiz Syed msyed@wikimedia.org wrote:
Themes is a feature I wonder if we really need. But from a design point of view would be fun to implement. Instapaper does a good job of this. http://iphonesoft.fr/images/appstore/288545208/instapaper.jpg
Watchlist, yes lets do it. We can take a similar approach as mobile web.
Searching within article, this feature has been in the Wikipanion app on iOS for ages. They dont do that good of a job with it as far as the interaction design is concerned but the feature works and is helpful too sometimes when you're looking for a fine-grained search within an article. If we do work on it, we should definitely make it better than what Wikipanion is doing. I have some ideas.
On Mon, Jun 9, 2014 at 11:00 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 10:51 AM, Dan Garry dgarry@wikimedia.org wrote:
- Dark theme! A dark horse... no pun intended. By far the most requested
feature
This is a regression as we've had it before. Dan, do we need anything from the designers to schedule this?
Watchlist. The most requested feature from the editing community.
Very interesting for the power user. Do we think that this would be enough or would users then need diff, revert, etc? Let's interview some users to not just know the "As a ..., I would like to" but the "so that" in this case to find out motivation.
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
--tomasz
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 9 June 2014 11:00, Tomasz Finc tfinc@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 10:51 AM, Dan Garry dgarry@wikimedia.org wrote:
- Dark theme! A dark horse... no pun intended. By far the most requested
feature
This is a regression as we've had it before. Dan, do we need anything from the designers to schedule this?
There are a few unanswered questions. Do we just have two themes? What goals are we trying to accomplish by adding them? I've set up a meeting on Thursday, 10:30 - 11:30 with Vibha, Moiz, Monte and Yuvi to figure this out and decide how we want to proceed. I'll prepare some Trello cards to help focus the discussion.
Watchlist. The most requested feature from the editing community.
Very interesting for the power user. Do we think that this would be enough or would users then need diff, revert, etc? Let's interview some users to not just know the "As a ..., I would like to" but the "so that" in this case to find out motivation.
I can do that quite easily through OTRS as there are a lot of emails from users asking for the watchlist.
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
I'll stick one in the next sprint.
Thanks!
Dan
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not seem too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard.
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not seem too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not seem too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO WRITE THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org
wrote:
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not seem too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO WRITE THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Searching within articles.
This falls into the same camp as tabs and browser features. Would be a fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not seem too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Yuvi, after today there's a potential I could spend a little time on this, unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend wire up? I did a local version without creating the control using the existing wireup classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is essentially a result count and the ability to scroll /forward/ in the Find list. It's sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and iterated scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway, highlight and scroll forward is probably sufficient if there isn't an easier solution to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS ( https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that for product direction for the apps. There were some performance things that would need to be worked out (see http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html for a little more context), but my gut says having a tappable finding glass icon (ideally on an embossed icon like most other search engines) to issue the fulltext Wikipedia article search in a fashion somewhat analogous to the web would probably be a way to avoid unnecessary load.
-Adam
On Mon, Jun 9, 2014 at 1:55 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO
WRITE
THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT
FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com
wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote:
> Searching within articles.
This falls into the same camp as tabs and browser features. Would
be a
fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not seem too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I posted a rough "Find in page" patchset for Android at https://gerrit.wikimedia.org/r/#/c/139310/. Here's what it looks like.
1 of 2. Page menubar: https://drive.google.com/file/d/0BxJX28FKLm78TGlhOHNDSXJLbjg/edit?usp=sharin...
2 of 2. Find in page dialog: https://drive.google.com/file/d/0BxJX28FKLm78YUVLNDZQazh6Nlk/edit?usp=sharin...
It works on a 4.4 tablet and and 2.3 phone with forward (down) and backward (up) scrolling. It seems on the pre-Jellybean devices the term highlighting doesn't work even if the viewport scrolls to the correct place, but the highlighting seems to work just fine on Jellybean and later.
-Adam
On Tue, Jun 10, 2014 at 11:28 AM, Adam Baso abaso@wikimedia.org wrote:
Yuvi, after today there's a potential I could spend a little time on this, unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend wire up? I did a local version without creating the control using the existing wireup classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is essentially a result count and the ability to scroll /forward/ in the Find list. It's sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and iterated scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway, highlight and scroll forward is probably sufficient if there isn't an easier solution to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS ( https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that for product direction for the apps. There were some performance things that would need to be worked out (see http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html for a little more context), but my gut says having a tappable finding glass icon (ideally on an embossed icon like most other search engines) to issue the fulltext Wikipedia article search in a fashion somewhat analogous to the web would probably be a way to avoid unnecessary load.
-Adam
On Mon, Jun 9, 2014 at 1:55 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO
WRITE
THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT
FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com
wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote: >> Searching within articles. > > This falls into the same camp as tabs and browser features. Would
be a
> fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not
seem
too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Thanks Adam. It'll be great to play with this.
--tomasz
On Fri, Jun 13, 2014 at 12:28 PM, Adam Baso abaso@wikimedia.org wrote:
I posted a rough "Find in page" patchset for Android at https://gerrit.wikimedia.org/r/#/c/139310/. Here's what it looks like.
1 of 2. Page menubar: https://drive.google.com/file/d/0BxJX28FKLm78TGlhOHNDSXJLbjg/edit?usp=sharin...
2 of 2. Find in page dialog: https://drive.google.com/file/d/0BxJX28FKLm78YUVLNDZQazh6Nlk/edit?usp=sharin...
It works on a 4.4 tablet and and 2.3 phone with forward (down) and backward (up) scrolling. It seems on the pre-Jellybean devices the term highlighting doesn't work even if the viewport scrolls to the correct place, but the highlighting seems to work just fine on Jellybean and later.
-Adam
On Tue, Jun 10, 2014 at 11:28 AM, Adam Baso abaso@wikimedia.org wrote:
Yuvi, after today there's a potential I could spend a little time on this, unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend wire up? I did a local version without creating the control using the existing wireup classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is essentially a result count and the ability to scroll /forward/ in the Find list. It's sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and iterated scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway, highlight and scroll forward is probably sufficient if there isn't an easier solution to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS (https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that for product direction for the apps. There were some performance things that would need to be worked out (see http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html for a little more context), but my gut says having a tappable finding glass icon (ideally on an embossed icon like most other search engines) to issue the fulltext Wikipedia article search in a fashion somewhat analogous to the web would probably be a way to avoid unnecessary load.
-Adam
On Mon, Jun 9, 2014 at 1:55 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO WRITE THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com wrote: > On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org > wrote: >>> Searching within articles. >> >> This falls into the same camp as tabs and browser features. Would >> be a >> fun spike to explore relative difficulty. > > Me and Adam actually explored this a while back, and it does not > seem > too hard at all. Only thing to figure out is where to put the > 'find' > bar, and the actual implementation doesn't seem too hard. > -- > Yuvi Panda T > http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Thanks to awesome work from Dmitry and Adam, the patch for 'Find in page' has been merged, and should be out in an alpha release in a few hours \o/
On Sat, Jun 14, 2014 at 1:14 AM, Tomasz Finc tfinc@wikimedia.org wrote:
Thanks Adam. It'll be great to play with this.
--tomasz
On Fri, Jun 13, 2014 at 12:28 PM, Adam Baso abaso@wikimedia.org wrote:
I posted a rough "Find in page" patchset for Android at https://gerrit.wikimedia.org/r/#/c/139310/. Here's what it looks like.
1 of 2. Page menubar: https://drive.google.com/file/d/0BxJX28FKLm78TGlhOHNDSXJLbjg/edit?usp=sharin...
2 of 2. Find in page dialog: https://drive.google.com/file/d/0BxJX28FKLm78YUVLNDZQazh6Nlk/edit?usp=sharin...
It works on a 4.4 tablet and and 2.3 phone with forward (down) and backward (up) scrolling. It seems on the pre-Jellybean devices the term highlighting doesn't work even if the viewport scrolls to the correct place, but the highlighting seems to work just fine on Jellybean and later.
-Adam
On Tue, Jun 10, 2014 at 11:28 AM, Adam Baso abaso@wikimedia.org wrote:
Yuvi, after today there's a potential I could spend a little time on this, unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend wire up? I did a local version without creating the control using the existing wireup classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is essentially a result count and the ability to scroll /forward/ in the Find list. It's sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and iterated scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway, highlight and scroll forward is probably sufficient if there isn't an easier solution to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS (https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that for product direction for the apps. There were some performance things that would need to be worked out (see http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html for a little more context), but my gut says having a tappable finding glass icon (ideally on an embossed icon like most other search engines) to issue the fulltext Wikipedia article search in a fashion somewhat analogous to the web would probably be a way to avoid unnecessary load.
-Adam
On Mon, Jun 9, 2014 at 1:55 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO WRITE THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote: > > Then i'd say rig a proof of concept for an hour or two and give it to > the designers to play with. Up to Dan of course. > > --tomasz > > On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com > wrote: > > On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org > > wrote: > >>> Searching within articles. > >> > >> This falls into the same camp as tabs and browser features. Would > >> be a > >> fun spike to explore relative difficulty. > > > > Me and Adam actually explored this a while back, and it does not > > seem > > too hard at all. Only thing to figure out is where to put the > > 'find' > > bar, and the actual implementation doesn't seem too hard. > > -- > > Yuvi Panda T > > http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Awesome work, guys!
It looks like on iOS we'll have to use some JavaScript magic to do the equivalent, but it's not impossible. We'll catch up soon enough. :D
-- brion
On Tue, Jun 17, 2014 at 11:54 AM, Yuvi Panda yuvipanda@gmail.com wrote:
Thanks to awesome work from Dmitry and Adam, the patch for 'Find in page' has been merged, and should be out in an alpha release in a few hours \o/
On Sat, Jun 14, 2014 at 1:14 AM, Tomasz Finc tfinc@wikimedia.org wrote:
Thanks Adam. It'll be great to play with this.
--tomasz
On Fri, Jun 13, 2014 at 12:28 PM, Adam Baso abaso@wikimedia.org wrote:
I posted a rough "Find in page" patchset for Android at https://gerrit.wikimedia.org/r/#/c/139310/. Here's what it looks like.
1 of 2. Page menubar:
https://drive.google.com/file/d/0BxJX28FKLm78TGlhOHNDSXJLbjg/edit?usp=sharin...
2 of 2. Find in page dialog:
https://drive.google.com/file/d/0BxJX28FKLm78YUVLNDZQazh6Nlk/edit?usp=sharin...
It works on a 4.4 tablet and and 2.3 phone with forward (down) and
backward
(up) scrolling. It seems on the pre-Jellybean devices the term
highlighting
doesn't work even if the viewport scrolls to the correct place, but the highlighting seems to work just fine on Jellybean and later.
-Adam
On Tue, Jun 10, 2014 at 11:28 AM, Adam Baso abaso@wikimedia.org
wrote:
Yuvi, after today there's a potential I could spend a little time on
this,
unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend
wire up?
I did a local version without creating the control using the existing
wireup
classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is
essentially
a result count and the ability to scroll /forward/ in the Find list.
It's
sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and
iterated
scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway,
highlight
and scroll forward is probably sufficient if there isn't an easier
solution
to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS (https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that
for
product direction for the apps. There were some performance things that would need to be worked out (see http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html
for a
little more context), but my gut says having a tappable finding glass
icon
(ideally on an embossed icon like most other search engines) to issue
the
fulltext Wikipedia article search in a fashion somewhat analogous to
the web
would probably be a way to avoid unnecessary load.
-Adam
On Mon, Jun 9, 2014 at 1:55 PM, Tomasz Finc tfinc@wikimedia.org
wrote:
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org
wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO WRITE THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote: > > GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT > FIRST. > > DAN > > > On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote: >> >> Then i'd say rig a proof of concept for an hour or two and give
it to
>> the designers to play with. Up to Dan of course. >> >> --tomasz >> >> On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com >> wrote: >> > On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc <
tfinc@wikimedia.org>
>> > wrote: >> >>> Searching within articles. >> >> >> >> This falls into the same camp as tabs and browser features.
Would
>> >> be a >> >> fun spike to explore relative difficulty. >> > >> > Me and Adam actually explored this a while back, and it does not >> > seem >> > too hard at all. Only thing to figure out is where to put the >> > 'find' >> > bar, and the actual implementation doesn't seem too hard. >> > -- >> > Yuvi Panda T >> > http://yuvi.in/blog > > > > > -- > Dan Garry > Associate Product Manager for Platform and Mobile Apps > Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Yuvi Panda T http://yuvi.in/blog
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
<quote name="Dan Garry" date="2014-06-09" time="10:51:06 -0700">
- Searching within articles.
Did "a real search" make it to the list?
That's one of my biggest peeves (tied with dark theme): When I'm looking something up on the fly (in conversation with someone), I want to type something in the search bar and have it do the right thing. IOW: if I don't know the article name or how to spell it, do a search! The "This page does not exist." message is the most demoralizing thing in my use of it.