A few suggestions for UX fixes/improvements

[CarlSinclair]

Disclosure: I run a DeGoogle privacy-focused blog and decided to test out Hauk for my listicle about Google Maps alternatives.

First of all, amazing project with amazing potential. But in its current state there's a few issues I came across.

1. The README.md suggests following the instructions in the installer, but there are none. It only asks if you want to open the config file immediately after installing and if you say yes, it opens an empty file. The part where it says config file is here: also shows nothing. It's very confusing for someone who's not familiar with the project and doesn't know where the config file is supposed to be. I reran the installer several times expecting instructions or a proper config file/path. I almost wrote it off as broken (especially given how fast the installer is and that it doesn't show progress or success messages) until I went looking in the files.

2. Neither the README.md nor the installer tell you that it adds a config.php file in /etc/hauk. It tells you to configure include/config.php which has no effect since /etc/hauk/config.php will override it. I was very confused why the app kept complaining about the server not supporting memcached when I clearly told it to use redis.

3. I completely disagree with Rephrase from "Encrypted" #96. Having two separate "password" configurations is far more confusing. I initially attempted to use password authentication as I'm only testing this myself, but I kept getting "incorrect password" whether I set the password as the encryption password or as the other password field leaving username blank, or both. I could only get it to work by switching to htpasswd. This confusion is exacerbated by the fact that the Android app doesn't follow the renaming convention suggested in Rephrase from "Encrypted" #96. Of course a user file is the proper way to setup Hauk for multiple users, but this makes me wonder if the communication is still E2EE with that option disabled, and why that option is offered at all if it doesn't work.

4. The Android app is currently useless for the end user. It allows you to share your location, but checking the locations of your friends requires opening a browser and going to the links they provided. It's a terrible UX when the map view should be a webview directly in the app with intents to automatically open share links. Without this, Hauk is a one-way location-sharing service. Implementing this would give it a feature that even Google Maps doesn't have, and that's bidirectional multipoint social location sharing. Most people currently use WhatsApp for that, to meet up or find each other in crowded places. This would be huge selling point for Hauk for personal safety at concerts, beaches, etc.

This would address and close #122 and eliminate the need for #177 and #206.

5. The web interface is obviously extremely limited (which is why it makes no sense why it can't be embedded in the app). But more importantly it's unintuitive and has broken links. The "person" icon should be accessible by clicking on the location markers, either your own or someone else's. And the "navigate to" link is broken. It opens a new tab with the href geo:coords,coords which obviously doesn't take you anywhere. This navigation link should give the choice to open navigation in Google Maps or OSM, unless directions and ETA are implemented as suggested in Destination and ETA #189 which would be nice.

This would address and close #181 and #189.

6. Allow the option to save location history to a file/sqlite, permanently. As someone who uses Google's location history to keep track of where I've been, I was looking forward to turn that off so I can save my location history to my own server instead. Sadly it seems that Hauk doesn't support this feature currently, which limits its utility significantly. Obviously it would have to be an opt-in feature on a per-server or per-user basis, but I think a lot of people would be interested in this functionality.

The answer to @bilde2910's question "Why not just use OwnTracks" is because OwnTracks is extremely complex and bulky with multiple moving parts. I'm reasonably capable with Linux and server management and I have not been able to set it up after two days of trying. As opposed to Hauk which took under 5 minutes and handles everything internally without the need for compiling and MQTT and multiple systemd services and reverse proxies between a broker and a recorder and a frontend. Privacy-friendly solutions mean absolutely nothing if they're not usable by the average person, and Hauk is, even in its current state.

This would address and close #130, #149, #174, #185 and #203.

Overall, Hauk is a very impressive product in its current state and it's very easy to get up and running (with the caveats discussed in 1-3) which is great for adoption. But without the feature requests discussed in 4-6 it seems incomplete and janky. I don't think any of these suggestions would be difficult to implement though. It seems to me that they aren't mostly for philosophical reasons, which is why I've made my arguments here for why they should be.

[CarlSinclair]

Also, here's how you block access to the root of the domain on Caddy, since instructions are only available for Nginx:

    @indexPage {
        path_regexp indexPage ^/(index.html)?$
    }

    handle @indexPage {
        @emptyQuery {
            not expression {uri}.matches("\\?.+")
        }
        handle @emptyQuery {
            respond 403
        }
    }

This works with the latest version of Caddy 2.8.4.

[zell-mbc]

4. The Android app is currently useless for the end user. It allows you to share your location, but checking the locations of your friends requires opening a browser and going to the links they provided. It's a terrible UX when the map view should be a webview directly in the app with intents to automatically open share links

I guess it's down to the use case. For my use case I wholeheartedly disagree with your statement that the UI is terrible/useless.
I use Hauk to share my location with my family when I am out on my bike. I need 2 clicks and probably less than 3 seconds in the Android app to share my location via our Signal Family group. All the recipients need to do is to click on the link, in a service they already use, Signal in our case. No need to install an app, no need to go out of their way. Part of the appeal of Hauk to me is that it's so dead quick and simple to use. And I would hate to tell them that they have to install (once) or open yet another application to check where I am.

That said, I can see your use case of sharing the location of multiple people. And if everyone is sharing and hence needs the Android app for this, the Android app would be a good place for location consumption/the map as well.

[CarlSinclair]

I understand the simplicity of not installing an app, but opening the app would be handled using intents. Clicking the link would open the app, if installed, or fallback on the browser. The main app view can still be the location sharing, to maintain the current seamlessness. The map view can be secondary, hidden behind a tab or a navigation menu.

By that logic, why not also enable location sharing through a webpage in the browser? That would be even simpler since nobody would need to install any apps. But we already have an app, so why not centralize everything in it? All it would take is a webview and some app intent logic. It would improve the UX significantly.

Remember, UX is different from UI. UX isn't about you. UX is about accessibility, and making it more approachable to the average person. If you're already running Hauk in its current state, then you obviously don't care about UX. An improved UX would increase adoption though, and at the end of the day isn't that what we all what? To encourage people to use more privacy-friendly options? What good is a wonderful project like this if nobody knows about it or if it's easier to use a big tech solution?