Wishing for Improvements to Linkedin
Wishing for Improvements to Linkedin
Verified Reputations is what Linkedin gives you. Super powerful. Except they have not really perfected it. Read on to hear my qualms with Linkedin and my suggestions for improvement.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
Verified Reputations is what Linkedin gives you. Super powerful. Except they have not really perfected it.
Linkedin’s Modeling of Jobs
In my working life, I’ve been a salaried employee, a freelancer arranging my own contracts (doesn’t happen in the US for tax reasons), a freelancer through an agency (who take a commission), and a consultant placed at one of my employer’s clients.
Other people have been "temps", "work for hire", "hire to fire" for something that superficially looks like a consultancy, but is really a "bodyshop" or umbrella company colloquially. In respect of interviewing candidates to hire, for periods of time that they were employed, I want to know that level of detail. Why? If they have more than one short stint in their recent years, it might have been a tough economic time, and they may have had to work for an umbrella company, or bodyshop. It might not be because they were crap at their job, or flighty.
In a related way, I’d like to be able to show the hierarchy of my jobs. ThoughtWorks had clients. I had not actually left ThoughtWorks to work at them. In LinkedIn, I’d like to be both a ThoughtWorker and a Googler at the same time (19 months up to Jan 2009). That is easily model-able, and straight forward to show in the UI.
Linkedin’s User Interface Problems
- URLs are terrible. RESTful, anyone?
- Back and forward problems
- Modality issues that irk
- Accepting/rejecting invitations is inconsistent between the two places in the app you can do it.
- For rejecting invitations, there’s no “Ask the inviter a little more detail on how they know me”-action that follows, allowing the inviter a second chance of being accepted.
Actions Toward Better Verification of Reputations
For rejecting invitations, there’s no consequences that follow–the inviter should fear getting dinged on a success-rate score for invitations. That way those crappy harvesters of profiles (towards crime, or merely getting your contact list without paying the Linkedin premium fees) will disappear.
Endorsement of Claims
People who are linked in to each other should be able to verify the individual claims made by each other. For example, two people who were at the same company for a period of time together should be able to score each other’s write-up for the period of time. For instance, if I claimed I was CTO at ThoughtWorks while I was there, a few hundred people could score me as 0/10 for that. If I later revised it to say "Chief TrunkBasedDevelopment Officer" the same people might get offered the chance to endorse the revision, I might then get an average of 9/10 for that claim (good enough).
Education is like jobs, of course–has overlapping timespans–can be scored by people there at the same time.
Qualifications? Especially vocational ones–that’s harder to score, but possible if issuing agencies get involved in Linkedin.
Clearly, for "colleague" style invitations, there is a need for a "periods of time" to be included. Indeed, after being initially linked two people might go on to be colleagues when they were not before, so multiple timespans would be eligible to be scored and not just at the time of invitation. It is all open to abuse though, so there needs to be a way of snipping the person that silently hates you while purporting to like you for the purposes of the invitation.
Of course, I want everything stored in JSON, YAML, or TOML format, and in source control. For reasons of privacy I might not be able to extract my connections’ details (or perhaps connections at all). I would want to see revisions though, and diffs on that. Source Control suits that.
Published at DZone with permission of Paul Hammant , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.