Open following5 opened 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 :)
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
... 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....
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
There are two possibilities:
Pro:
Pro:
Con:
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
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.
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.
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.
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.
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
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...
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.
@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...
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.
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
Spinoff from #1922
@kojoty
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. :-/)