I previously used KeePassX, which was great due to the multiplatform support. However the project seemed stalled, and I've since switched to the excellent KeeWeb; it's Electron based and is in general more modern.
I'm very interested in trying it, just a little worried about it's stability. I guess I'm slightly biased against Electron apps due to some bad experiences.
I'm just worried it will corrupt the database or something.
Not OP, but I've been using it for work passwords since spring 2016, and finally started using it personally in the last few months.
I had one UI-related saving issue, but the creator quickly responded to the PR and fixed it in a later version.
San Francisco, CA and Cambridge, MA - Locu is hiring Frontend Engineers,
Backend Engineers and Visual Designers for Full-time
Locu helps local businesses Get Found. With a patent-pending technology platform that digitizes and structures real-world data, Locu is building tools that help businesses connect with customers. Locu’s content platform is the easiest way for merchants to keep business information, menus and price lists updated and distributed across the Web, and Locu’s API gives developers access to the world's largest real-time, structured repository of local business data. Over 40,000 local merchants are using Locu to promote their businesses online. Locu was founded by MIT graduates and is backed by investors including General Catalyst Capital Partners, Lowercase, Lightbank, and SV Angel. Our beautiful offices are in downtown San Francisco, CA (Union Square) and Cambridge, MA (Kendall Square). Check out photos and learn more about our other perks:
If you are passionate about building products that will touch millions of merchants and hundreds of millions of consumers through the applications powered by our local data APIs, Locu is the right place for you. [JQuery, Less, Django, node.js, etc.]
Backend engineering
We started Locu out of MIT to solve real-world problems by leveraging the latest research in computer science. If you are looking to solve some of the most challenging problems in machine learning, NLP and human computation, you'll feel right at home. [Python, Django, Node.js, Postgres, Redis, AWS, etc.]
Design
We're looking for visual designers who are excited to redefine what the future of local business data looks like across web and print, and to create tools that put modern web technology in the hands of merchants.
Interested? Drop us a line at jobs@locu.com. Please include "[HN]" in the subject of your letter. Learn more about us (now with photos!) at: http://locu.com/about/jobs/
GoDaddy has one job: making sure that, with regards to domain names I've purchased, people accessing them get sent to IPs which I control. GoDaddy just demonstrated that they're capable of failing at their one job if anyone applies a determined high schooler level of intelligence to defeating their security processes.
I run a business which collapses catastrophically if I lose control of my Internet presence, and I'm at least as Internet-exposed as "a guy who owns a desirable Twitter handle."
I don't care about elephant hunting. I put up with years of my intelligence getting insulted by SSL certificates being hawked by models. I can appreciate that the economics of the business mean that there need to be upsells to continue offering the low low prices. Fine. But if you cough up a domain, that's it, we're done. I care about that like Thomas cares about SSL CAs offering a CA=true cert to a third party.
I recently went through an acquisition where we transitioned from Google Apps to the Microsoft suite. I do not share your love of Microsoft's suite.
Among the many problems I have with the Microsoft suite, Outlook is at the top of my list for generating the most frustration. GMail's priority inbox and new-style inbox where machine learning is used to sort out mail is a productivity booster for me. With Outlook, I regularly lose important mail because it is buried under the difficult to filter masses of other email.
I could go on about how the lack of robust collaboration facilities are a direct time waster for my team, but I don't want to hijack this thread further...
To the OP, insisting that apps running in browsers will never match native apps in terms of UX, that's a very audacious claim.
There are many powerful, competent, and well-funded entities with a vested interest in improving the web app experience (including Google). I wouldn't claim they're doomed from the start. This could be just another example of a disruptive technology, that's initially lacking in certain conventional metrics, but has a lot of room for improvement above and beyond the entrenched competition.
> There are many powerful, competent, and well-funded entities with a vested interest in improving the web app experience (including Google). I wouldn't claim they're doomed from the start.
I've been using gmail for almost 10 years. I liked it from the start. But it's getting worse, not better. It's extremely slow compared to what I'm used to with Exchange and Outlook, and navigating around is more of a chore. How do I, for example, see who's in on an email list? I can't just right-click on the name of the list and see the members? (And don't even get me started on the new compose experience mess.)
If Gmail was being continuously improved, I'd have a reason to be optimistic about it. I like being given free storage, but as far as usability goes, I have fonder memories of Eudora.
A lot of it is due to the limitations of HTML. For example, HTML is why Gmail paginates about as well as PHP app from 1998, instead of allowing you to just scroll through all of them like a native client.
Nonsense. FastMail's webmail allows you to scroll continuously through (or jump to any section of) your mailbox, even when they have 100,000+ messages in them. (Disclaimer: I work for FastMail). This is not an inherent limitation of the underlying technology, just one of implementation.
> For example, HTML is why Gmail paginates about as well as PHP app from 1998, instead of allowing you to just scroll through all of them like a native client.
No, its not. HTML + JS, via AJAX, supports infinite scroll with a finite amount loaded at any given time. IIRC, Google has used that on Google Image Search and some other properties.
There may be web platform associated performance or other considerations behind pagination, but its not a fundamental can't-do limit of the technology.
Pagination does have it's advantages, namely:
- Linking
- Easier to grok where you are in the result set ( 3 out of 5 instead of the scroll bar that changes height)
That could definitely be part of it. Outlook isn't dumbed down because it's not primarily aimed at home users. Maybe Gmail makes sense for few people in the office the way Outlook makes sense for few people at home. That doesn't change the fact that the bandwidth/latency profiles are different going to the server room in the building than going out to the internet. But I might see a big improvement over what Gmail is now if Google was being designed for business users.
For starters Google could of kept compatibility with the activesync protocol instead of making calender sync with outlook the horrific monster it is today. Actions like this are just one of the multiple reasons I tell people to not invest invest Google business products.
Because I could then build the entire interface client-side in a browser?
Don't get me wrong, I'm not a webdev guy. I have no front end/fullstack experience. I'm a longterm sysadmin/DevOps person. But if you're a power user, you want control over your mail interface/workflow. In that case, all your mailserver should be doing is accepting email for you, storing and indexing it, and serving it via API to clients you're using. I like IMAP, but it doesn't easily support some Gmail conventions (multiple labels per message).
IMAP and SMTP could easily be condensed into an XML/JSON API that could be done over HTTPS; I'm not familiar enough with CalDAV to say that though.
I believe ops point was that any stable api would be preferable to: "Yeah, there's an api, but we refuse to document it, and we'll randomly depricate stuff if you try to use it to build something that isn't gmail". The team behind gmail is probably one of the best qualified to hammer out a working api for email of json (what we have + a bit of what we want + stability and versioning). No reason why they couldn't publish that as an RFC and let people implement a front end for dbmail or whatnot that spoke the same api.
Gmail should not be indicative of whether or not web apps can match desktop apps. It should be indicative of whether or not the engineers behind Gmail have focused on making it work as well as a desktop app (they have not).
They've spent a lot more time making Gmail Offline work well. Maybe sometime in the future they'll spend time optimizing; but it's probably not a priority
>> It's extremely slow compared to what I'm used to with Exchange and Outlook, and navigating around is more of a chore.
Its performance is fine from what I see every day. Plus it integrates with my phone and my home Linux desktop via the browser very nicely. Navigating is different but not worse than Office by any stretch, just my opinion.
Some of us don't like any of the current alternatives.
In my opinion Gmail beats Outlook for mail, but Google apps are not really enterprise-ready for calendar and docs. Editing a document offline is not a feature that should just now be becoming sort of usable, it should have been fundamental from the beginning. Confusion between Google Apps and personal Google logins is common. Managing a Google calendar is painful, and basically has not improved at all in years.
I have no desire to go back to using Office for everything, but I have very little confidence that Google is actually going to spend much effort in getting things right for these use cases either.
They are set back and certainly extremely limited from the start. Native means you have almost unlimited capabilities for interacting with the user and their system. A browser application by definition is much more limited. The experience is always improving but it's to get the point that native applications have always had -- and they still have a long way to go. And the nature of browser based applications might mean that it can never happen. The browser is layer between the solution and the user and it will always interfere in some way.
Not having to attach files for even the slightest change is so much better. I really miss working for a company that uses google apps.
Everything was online and centrally controlled. Jira, Confluence, AWS, Github, MediaWiki (some of these were self-hosted), and google apps.
I have always preferred centralised computing, you can visually see the headaches and frustration drop for IT support technicians when they don't have to deal with minor printer, file, or collaboration issues. The kind of issues that were created by the "PC" in the business environment.
San Francisco, CA and Cambridge, MA - Locu is hiring Frontend Engineers, Backend Engineers and Visual Designers for Full-time; H-1B is OK
Locu helps local businesses be found. With a patent-pending technology platform that digitizes and structures real-world data, Locu is building tools that help businesses connect with customers. Locu’s content platform is the easiest way for merchants to keep business information, menus and price lists updated and distributed across the Web, and Locu’s API gives developers access to the world's largest real-time, structured repository of local business data. Over 30,000 local merchants are using Locu to promote their businesses online. Locu was founded by MIT graduates and is backed by investors including General Catalyst Capital Partners, Lowercase, Lightbank, and SV Angel.
Our beautiful offices are in downtown San Francisco, CA (Union Square) and Cambridge, MA (Kendall Square). Check out photos and learn more about our other perks: http://locu.com/about/jobs/
Frontend Engineering
If you are passionate about building products that will touch millions of merchants and hundreds of millions of consumers through the applications powered by our local data APIs, Locu is the right place for you. [JQuery, Less, Django, etc.]
Backend engineering
We started Locu out of MIT to solve real-world problems by leveraging the latest research in computer science. If you are looking to solve some of the most challenging problems in machine learning, NLP and human computation, you'll feel right at home. [Python, Django, Node.js, Postgres, Redis, AWS, etc.]
Design
We're looking for visual designers who are excited to redefine what the future of local business data looks like across web and print, and to create tools that put modern web technology in the hands of merchants.
Interested? Drop us a line at jobs@locu.com. Please include "[HN]" in the subject of your letter. Learn more about us (now with photos!) at: http://locu.com/about/jobs/
San Francisco, CA and Cambridge, MA - Locu is hiring Frontend Engineers, Backend Engineers and Visual Designers - Full-time; H-1B OK
Locu helps local businesses be found. With a patent-pending technology platform that digitizes and structures real-world data, Locu is building tools that help businesses connect with customers. Locu’s content platform is the easiest way for merchants to keep business information, menus and price lists updated and distributed across the Web, and Locu’s API gives developers access to the world's largest real-time, structured repository of local business data. Over 30,000 local merchants are using Locu to promote their businesses online. Locu was founded by MIT graduates and is backed by investors including General Catalyst Capital Partners, Lowercase, Lightbank, and SV Angel.
Our beautiful offices are in downtown San Francisco, CA (Union Square) and Cambridge, MA (Kendall Square). Check out photos and learn more about our other perks: http://locu.com/about/jobs/
Frontend Engineering
If you are passionate about building products that will touch millions of merchants and hundreds of millions of consumers through the applications powered by our local data APIs, Locu is the right place for you. [JQuery, Less, Django, etc.]
Backend engineering
We started Locu out of MIT to solve real-world problems by leveraging the latest research in computer science. If you are looking to solve some of the most challenging problems in machine learning, NLP and human computation, you'll feel right at home. [Python, Django, Node.js, Postgres, Redis, AWS, etc.]
Design
We're looking for visual designers who are excited to redefine what the future of local business data looks like across web and print, and to create tools that put modern web technology in the hands of merchants.
Interested? Drop us a line at jobs@locu.com. Please include "[HN]" in the subject of your letter. Learn more about us (now with photos!) at: http://locu.com/about/jobs/
