opencaching / opencaching-pl

The source code of Opencaching.PL (and some other domains)
https://opencaching.pl/
GNU General Public License v3.0
22 stars 33 forks source link

Mobile strategy #1928

Open following5 opened 5 years ago

following5 commented 5 years ago

Spinoff from #1922

@kojoty

Currently mobile page is almost not used - in Jan 2019 we had 328 views (during the whole month!)

May eventually be similar for the main page, because most users have switched to smartphone apps. ;-)

I believe that any OC site will fail that is not accessible in a way which has been optimized for smartphone use from scratch. The legacy OC user interfaces like current https://opencaching.pl won't make it - a completely new set of mobile-optimized templates is needed.

But agree that the current mobile page is very outdated; for most tasks c:geo is the better choice. May be easier to create a new one upon the refactored Controller/Model codebase, than refactoring the existing mobile page. Or improve OKAPI and write a dedicated OC app for smartphones.

(Just dreaming ... I am aware that currently there are no developer ressources available for hat. :-/)

kojoty commented 5 years ago

@following5 yes I agree that current OCPL PHP app is also little-bit oldschool web interface for PCs, but half of the traffic is from PCs and I hate editing anything on smartphone - smartphone is great to read something - but usually I turn on laptop when I want to answer email or github discussion - so I think web interface for bigger screens is still an option - and that's why I still spent time on this :)

kojoty commented 5 years ago

about mobile:

I also dream about "mobile friendly" OC webpage and I believe it's not so far as sometimes it could look like...

There are nice web solutions like CSS Grid Layout we need to use to hide sidebar on mobile + adjust most popular pages and we are almost mobile friendly.

First we still need refactor of a few big parts of OCPL code:

checked above are more-less done

kojoty commented 5 years ago

... and then what we need is to prepare responsive main layout with hidden sidebar etc. and our site will be much more mobile friendly...

I don't know how long time it takes - but I expect that somewhere in next year....

kojoty commented 5 years ago

and of course there is a huge place for mobile apps but I expect that web interface will also be still in use in next years

andrixnet commented 5 years ago

There are two possibilities:

  1. keep mobile pages, update them with most recent features and changes, but redo templates to modern style mobile responsive, yet keep them simple. Use an user agent detector to redirect automatically to the mobile pages if accessed from mobile.

Pro:

  1. drop mobile section completely. Redesign templates on main site to be responsive and desktop&mobile friendly.

Pro:

Con:

  1. I wouldn't recommend starting yet another mobile app. AFAIK c:geo does an excellent job and I doubt OC has the developer resources to start and maintain such an up.

As a side note, I would like to ask other OC people to recommend to c:geo team better "first use experience". See: https://github.com/cgeo/cgeo/issues/4263 https://github.com/cgeo/cgeo/issues/5927 https://github.com/cgeo/cgeo/issues/6539

following5 commented 5 years ago
  1. Create a new, mobile-optimized Opencaching website based on OKAPI. Will easily run on any device; much simpler than providing a new app.

AFAIK c:geo does an excellent job and I doubt OC has the developer resources to start and maintain such an up.

c:geo is optmized for GC and rather incomplete. Many important OC features are not supported, like

OKAPI is planning to implement editing cache listings, which will never make it into c:geo. And c:geo user interface is unintuitive; could be done much better with a clean new app.

kojoty commented 5 years ago

Ad 4. Creating "new website" (Not a mobile APP) from scratch is always a tempting idea, but I think it is not a best way in our position. If we go this direction we just split our time resources between two projects - because we still need to maintain current website.

Don't forget that if you start something "new" there will be a new ideas which will need refactor also in "old" project - for example any change in DB...

I think that there is no sense to start "new" in our situation, especially that creating "new" is not much easier than refactor the old code.

Most of views we have are quite simple - just the list of caches for example. If we change the layout (I mean this what now we have in /tpl/stdstyle/common/main.php) many pages will be much more useful on mobile.

There is really not so much necessary changes. Maintain the one tree of the code is much more easy that maintain two separate applications.

  1. What we still don't have is an Geocaching APP supports OC for Apple devices... - don't forget C:geo is only for Android...
following5 commented 5 years ago

An OKAPI-based mobile website does not access any DB, and it does not need to be based on OCPL or OCDE source. I was rather thinking of an independent project, which starts from scratch. Rebuilding the current functionality of OCPL mobile page should be achieavable within a few months.

following5 commented 5 years ago

Then add a map and some more of the existing OKAPI capabilities, and it already is more versatile in terms of OC feature support than OCPL mobile and c:geo.

kojoty commented 5 years ago

Sure, but any "web app" vs native mobile app (like c:geo) has a main problem: offline mode - this is the great feature of C:geo and native apps at all - it allow to store data for offline use - this is the main feature for me because in terrain mobile internet connection is often poor Maybe there are also some mechanisms which allow to store offline data in browser but I'm not sure if this is the same - for example can you open offline map with offline caches in web app - I don't think so - so any web-mobile-app is in my opinion only something "additionally" to main site and native app like c:geo

kojoty commented 5 years ago

Another thing is "a changes in DB". Of course that the mobile-app which uses OKAPI will not access any DB directly. But in fact it will read and store the data by OKAPI - and for sure there will be requests which will need to change something in OKAPI what will be a cause of change in server side... Do you think that OKAPI now has all what is needed except cache editing? I believe there will be many "requests for features" which will need changes in OKAPI...

following5 commented 5 years ago

The "offline problem" also applies to the OC websites. So when offering a mobile-optimized alternative to that, there is no disadvantage regarding offline usage.

The feature request thing applies to any OKAPI client. We did several OKAPI improvements in request of c:geo users, but they never needed a change in OC databases.

kojoty commented 5 years ago

@following5 I think I can agree in general...

Let's conclude: I only wanted to describe the situation:

of course we can introduce third option: web-app for mobiles created from scratch - I think this is something "in-a-middle" and I'm not sure if we have enough resources to maintain it all - that's my main thinking about this. I'm not against it...

okainov commented 4 years ago

c:geo is optmized for GC and rather incomplete. Many important OC features are not supported, like

recommending and rating caches editing and deleting logs all log types except "found", "not found" and "comment" OKAPI is planning to implement editing cache listings, which will never make it into c:geo. And c:geo user interface is unintuitive; could be done much better with a clean new app.

Just a random comments from main geocaching.su maintainer here :) In short - you need to implement that :) It's not like "cgeo doesn't support it" but rather "you need that - contributions welcome". So someone really needs to sit down and write some Java code. And TBH I found it quite manageable for myself while I'm not Java dev at all. In particular for recommending caches see https://github.com/cgeo/cgeo/issues/7183 and my WIP change mostly unblocking the c:geo core for you to implement it in the easy way https://github.com/cgeo/cgeo/pull/8361 We had the similar branstorming for us in Geocaching.su, but it was quite obvious that we have neither desire nor enough qualified and willing to code people to start and maintain our own app. In the meantime c:geo provides incredible base (with well-known issues, yes, but there is nothing which cannot be improved) and it's much easier to reuse the platform and implement something based on it.

kojoty commented 4 years ago

It's not like "cgeo doesn't support it" but rather "you need that - contributions welcome"

yeah... but it seems for now I also don't know anyone who can prepare such changes... but I agree with this approach