There’s about zero overlap between the favorites in my phone and on the computers though. Different missions and all that.
Not to mention different brands of incompatible browsers hooked to different brands of incompatible clouds. One time imports are fairly easy across brands or clouds. AFAIK full-up sync isn’t.
Yep It would be. The link wouldn’t even exist on your home computer. It would be in you mobile device that you scanned from the screen on your home computer.
Not everyone syncs their devices. It will probably happen some day. I sure don’t. I’m not going to try to manage my servers from a smart phone.
And LSL, yep, I think most of us do a bit of investigation before we grab our phone and hit the road. Having an easy QR to get the mobile app url is helpful.
I forgot what city I was in (it was back when I was traveling for work a lot) but one of the most useful QR code thingies I saw was that they had a code printed on the signs for every bus stop, and if you scanned it, it took you right to the schedule for that bus, including any service change announcements, and a map thingy showing you exactly where the next bus was in relation to your stop.
In a nutshell, that’s the kind of thing QR codes are exactly right for. Fast access to data too complex to transfer any other way from a static display.
And while I now grasp enipla’s idea, it’s still a bit of a clank to use a static image on an interactive display for machine navigation. So many other and more organic approaches.
Um… what? “machine navigation”? This has nothing to do with navigating on the existing site or PC that the user is on. It’s about finding where you want to go and easily saving a url that is made for mobile devices. And running with it to be used with a specifically developed site that is designed for mobile devices.
The QR is simply a link for a specific app for mobile devices for trail information.
In my example, a user can find what they are after, use the QR to access the mobile site and then go to breakfast and since the QR is so easy to load to a mobile, they now have info/maps/uses/parking info for everything that they may be interested in without having to digest the entire site to get to it. And it has maps, directions and where the heck they currently are.
So does your QR code navigate the mobile device’s browser to your GIS website tailored for mobile display? Or does it navigate to an app store to download and install a dedicated app that does the rest of the GIS and current info magic?
No app is downloaded. No need. And as I am government, we just don’t go that way.
The url will automatically fit to any display size. iPhone, Galaxy, netbook, or desktop. Yep, it’s kinda crazy. It does not limit data based on device. ~ well, we aren’t trying to push that much with this one. (though I have one coming that will allow much more data. Easy peasy)
I can’t take all the credit. ESRI is the GIS software company that 90% of mapping software is running on. I am standing on the shoulders of giants. My main mapping info site for the county gets 15,000 hits a day though. 30,000 people live in the county. 10,000 lines of my own code.
The Trails mobile application (I should not call it an app) is in the pipe. Pretty much ready to go. All data is ready, it may need a little polish and approval. The wheels of government move very slowly.
An odd little fact ~ I have been in GIS (Geographic information Systems) before it was called GIS. I started in 1988. It was called AM/FM back then - Automatic Mapping / Facilities Management. I saw awards on the wall for our company. AM/FM ? The hell?? Are we in radio broadcasting too?
QR codes are useful, but there are some contexts where they can be an open door to hackers - in a previous job (local government) the parking service wanted to put QR codes on all the parking signs that would take the user to a payment portal where they could pay for their parking.
With something like that, it would be really easy for someone to walk around the city and just to overlabel the QR codes with a URL that went to their own fake payment portal (take a payment, but report ‘there was a problem - no payment taken’ - then redirect the victim to the real payment portal - as scheme like that could potentially run for days or weeks before it was eventually detected.
Okay. I think I finally grasp your intent and while I think there are better overall approaches, I can’t say it doesn’t make sense.
However, it’s a niche solution with a very narrow range of applications, based on a very fleeting moment in conjunction of technologies. Next year, something like Bluetooth or NFC will allow far more sophisticated transfer to a mobile device without the kluge of using a static link symbol that needs a special mobile app to read and process.
In general, a static link of any kind on an interactive display is a design mistake, almost as big a one as a long, complex URL on a printed item.
Sure, not everyone will have a QR reader, or know how to get one. And we will of course provide the URL so they can enter it manually. I think it’s kind of silly to create an app to download that is nothing more than a shortcut (and not sure how that would fly WTPTB).
The URL is 104 characters long. I’m sure I’ll do some sort of redirect to shorten it.
The key in info transfer is to make it easy. If I have you right, the user has access to an interactive display that lets them browse for trail information, and then there’s a need to let them easily DL the selected hike’s info to their phone? I have to say a QR code would be the right tool for that, at this time and place. It’s like PDF maybe five years ago: not everyone had Reader, but it was getting damned hard to access a lot of information without it. So those who don’t have a simple QR reader won’t be terribly inconvenienced by having to get one to take advantage of the system.
A short-linked URL, even just a ‘www.domain.gov/A1B2C3’ kind of thing, would be a useful backup.
Next year, the kiosk will have BT or tap-to-read and it will be a different issue.
Fixed QR codes at trail heads and other useful places, with links to whatever is important at that point, would be immensely useful, of course.
The user would likely first visit our main web page and look for trails information. On the page that gives info about our Open Space and Trails Department, would be the link and or QR to take you to our GIS trails website. That site will be designed for a mobile device (or no problem if you just want to use it on your desktop). The ‘mobile’ application/site will be an interactive GIS map that a user can select different trail heads or trails and get the data about that trail. It will also route them to it from their current location.
The site will have the data for ALL our trails, there is not a different website for each trail. One use will be for a user to pick and choose and get trail information before they even decide where to go.
Then the QR code serves no useful purpose. If they are simply on a web site, an ordinary link can take them to the mobile version.
If you are postulating that they’re on a “computer” scale browser but want to jump to a mobile version, a QR code might be a good way to do that, but you keep saying that’s not the case. Exactly where do they switch modes from browsing you on a ‘regular computer’ and following up on their mobile device?
ETA: for clarity, I would regard “getting the phone’s browser to point to a specific link” as a variant of “downloading info to the mobile device.” I can see the distinction but think it’s unnecessarily fine - you want to get info from the computer-browser screen into the mobile device so the latter can navigate to a specific, mobile-friendly site. In user perspective, that might not be “downloading” anything, but in technical terms, you are DLing the mobile address.