Passionate about developing apps?
Want to be recognized among the XING community?
Want your app to reach millions of people?
Want to be famous?

If you answered yes to at least one of these questions, you’ve definitely come to the right place! We came up with a new idea where developers now have a chance to introduce themselves and their app in this blog. To get the ball rolling, we decided to ask Marvin some questions about his experience and from now on Marvin will use his awesome-app-detecting spotlight to find the super developer. Here are his answers for the questions we asked.

What’s your XING application / integration all about, and what do you want to accomplish with it?

Building up an online professional network around you is awesome, but what goes beyond that is the opportunity to meet this network via offline events. I decided to make use of the geo-locations call in my app, which helps you find out which of your contacts are nearby. Once you’ve found out who is nearby, you can send that person a one-click invitation with a short message to let them know you’d like to meet up with them. You can also add this person to your contacts with a single click.

What were your expectations when you started developing with the XING API?

Like every other developer’s wish, I expected clear and simple documentation about how to get started and insights into every API call, which narrows down to my direct needs, and the XING API gives me just that. Whenever I had any technical doubts or questions, the support team was always on hand to clarify things. I also hoped to have an SDK, but that was missing so I had to dig around in the dirt and start from the search. But isn’t that the best way to do it anyway?

What tips would you give to someone who is just starting out developing apps with the XING API?

RTFM. For those who don’t know what that means, it stands for Read The Flipping Manual. Everything you need is in there. It tells you how to get  started, it gives you the core concept, and it shows an overview of all API calls and much more. That should help every developer to get up and running. On top of that, there are lots of human beings helping each other, sharing their knowledge and expertise, and trying to find answers in our community. Why don’t you join the conversation too? The API changelog is a great way to keep an eye on the changes and new features they bring to the API.

Why did you choose to develop for the XING platform?

My soul is German engineered and I felt the spirit at XING, where I really could see what is happening now and what will come in the future. And XING is a well known and the largest business network in the DACH region and I target users from the same region. Millions of business professionals are on XING, which makes me confident that my app will be engaging. So I obviously chose to develop for XING.

What do you like most about the XING API?

My engineering soul really connects with the XING API because of its chattiness and the fruitful response it returns, be it a nice 200 or even a 404.

What do you think is missing or should be improved to make the XING API more attractive?

It would be awesome to have the user search API, Jobs API and company profiles. These are a few important things that are missing from my point of view. It would also be great to have app usage statistics, such as how many access tokens my app has and the number of requests via my app.

How active are you on XING and which services do you use most often?

I’m more active on XING than you probably realize. I love the fact that I can take my XING app everywhere I go. Everyone likes to know what’s going on in their network, so the network feed is very handy. For me as a robot, it’s awesome to be a part of this community where developers exchange information, get to know one another, and learn a lot.

It all started while I was looking for a job and found out that XING wanted to have a mascot for their API. My main job here at XING is to represent the XING API, which is why I know all about the technical aspects of the API, ranging from legal aspects through to branding guidelines. I’m sure they couldn’t think of anyone better than me for this role!

Here at XING a small group of testers adopted another approach. We took part in a test competition organized by Matt Heusser: http://www.nrgglobal.com/general/more-on-the-test-competition

For us it all started on January 22nd like this:

In addition to Alina Avadani, Tobias Geyer and Brindusa Axon (an ex-XING colleague), a short survey involving the XING QA team prompted Katharina Gillmann to also join the team.

We held an intense private conversation on XING (of course!), trying to come up with a name for the team and agreeing on how to organize and communicate. We finally agreed on “The 4 Musketeers” and then completed the registration process.

After picking a timeslot for the performance testing part of the competition (functional testing was from 4 to 7 pm on April 19, while performance testing was from 1 to 4 pm on April 20) we all felt set and ready to go. By the way, converting those times from and to EST was a nice reminder that time zones are an important testing topic :)

The competition topic came up again of course when we saw the blocked times in our calendar :) and started to prepare our environments and test our credentials for TeamPulse, the bug tracker we had to use.

In an attempt to not disturb normal business in the office too much we had a meeting room for this and on Friday around at 3 pm we started to prepare and move laptops, monitors, food and drinks to Reeperbahn (the meeting room, not the infamous street). Shortly before the competition began we started a video conference session with Brindusa because we were an awesome distributed team, working from both Hamburg and London.

Friday was reserved for functional testing.

Until the competition started at 4 pm we had no idea about the requirements and what to test. The only thing we knew was that we had to test a “plain vanilla” web application. All of the important remaining information was delivered just a few minutes before kick off, so we had to organize ourselves very quickly in order to avoid wasting time.

The organizers delivered four different web applications for us to test (for details see http://www.nrgglobal.com/general/test-competition-rules). We were given a choice of either testing all of them or only focusing on one or two of them. In the second case we had to give a reason why we focused on that specific application.

In addition to the bugs we reported we also had to create a test report within the 3 hours and deliver it via e-mail at the end of that time period. The repost should contain information about what we tested, critical findings, our recommendation based on the findings, and what testing methods we used (which mostly involved exploratory pair testing).

But before we were able to start testing we had to talk to the customer to get all the information we needed such as which kind of functionality has a high priority and which parts should we focus on (usability, functionality, security, cross-browser functionality and mobile devices).

After discussing this with Matt (who acted as our customer for all of the apps) we decided to focus on the following two apps:

QuickEasySurvey.com : A tool for creating and taking surveys

CorkBoard.me : A corkboard, shared over several users, with the possibility to add notes.

Thanks to Alinas persuasive skills, we also had a special guest, Giorgos Avramidis, who is one of our Rails developers. Other colleagues also visited us from time to time, all of whom showed a lot of interest in what was going on.

Within a few minutes after getting started we were completely immersed in the topics and found quite a few critical issues. In the case of CorkBoard.me most of the issues were related to cross-browser functionality and usability of the board. As a bonus we also found some security issues. At the end we also crashed the entire app in our local browsers.

For QuickEasySurvey there were critical functional issues (like the results not being stored on the server) as well as security concerns (e.g. seeing the statistics for other peoples surveys)

As we saw afterwards, it was a good idea to pair up in both cases, as this allowed us to simulate multi-user scenarios more easily. Having a developer on the team also helped a lot as he kept coming up with issues he discovered when reviewing the visible parts of the application code.

Everybody knows that time flies when you’re having fun and that was definitely the case her. Having to deliver the test report on time proved to be a bit stressful in the end because we kept finding bugs, having fun and no one wanted to move on to writing the “boring” report. We managed to finish it just 5 minutes late which hopefully won’t earn us too many penalty points.

On Saturday we did some performance testing and even though none of us is an expert at this, we did a hell of a job!!! Tobi’s previous experience with performance/load testing using JMeter was a big advantage for us and the JMeter training we did a few days before was very helpful.

We had 3 hours for performance testing on the Survey app mentioned above. Every team had a special time slot reserved for that, so no one else was working on the app during that time frame.
We also talked to the customer for our performance tests. We were informed that the platform should be stable for 25 users working in parallel with the application and that a request shouldn’t take longer than 5 seconds. We started with some easy performance tests, which already showed up a number of problems for the application because the average response time we measured continually increased with every run to a multiple of 5 seconds. After that we increased the load on the platform and immediately crashed the entire database. And we appeared to be the first team to do that as you can see in the comment from Matt ;)

Like all good testers we don’t believe in a result if we can’t reproduce it so the app developer had to restore the database a few times until we were satisfied with our findings.

This time we also learned from the day before, so we started writing the test report much sooner and were almost on time when we delivered it.

One thing we want to say in general is that IT WAS AWESOME!!! It was a welcome change from our daily work, an interesting and useful QA event, and 8 amazing/crazy/funny hours spent with the coolest team!

And before someone asks what the prize is, we don’t really know :) None of us knows because winning was not our goal. Our approach was Let’s have fun and let’s test it!!! And that was exactly what we did. Every single one of us can highly recommend you take part in such a contest, even if you’re not a tester or don’t have any testing skills. Giorgos enjoyed the contest just as much as we did, and it was very interesting for him as a developer to see the other side of a development process.

The results of the competition haven’t been published yet but we’ll keep you updated.

Experimental

Experimental calls are fully specified, implemented, tested and can be accessed by any test consumer. We specifically have this status in our API so that developers who experiment with these calls can provide us with valuable feedback, which in turn allows us to figure out what needs to be improved.

Our goal is to bring these experimental calls to production within three months or less. We may apply breaking changes to these calls during the experimental phase, meaning that production consumers will not be able to access experimental calls.

Production

Production calls are guaranteed to be future-proof and can be used in production by all consumers. Future compatibility means that no incompatible changes will be introduced to the production calls.

Additional features may be added to the production calls as compatible changes. This means that either (an) additional parameter(s) may be added to the call request or that additional data may be added to the call response without having any side-effects on the existing production call features. API clients need to handle responses flexibly, i.e. extract data by navigating the structure rather than relying on a fixed response structure.

Deprecated

Calls marked as deprecated shouldn’t be used any more (new applications shouldn’t be built this way) because newer versions of those calls are available. Deprecated calls will be removed completely in later versions of the API.

If a consumer is using a deprecated call, the response will include the X-XING-Deprecation-Status: deprecated HTTP header. Consumers/Applications can and should use this information to let the user know that he needs to update his application.

We hope that this post provides you with a good understanding of the lifecycle of API calls. For other topics regarding the XING API please check out our documentation.

As mentioned in that article, Chrome at one point natively handled what we implemented in a heavily jQuery based way. Having that said, it means they went against the specification, which may seem weird, but no one ever said that a specification is set in stone. (I’ll refer to that again later.)

Other browsers handle this the same way in their newer versions (Safari, Firefox) with the placeholder presented to the user while the input is focused. Both solutions have their advantages and disadvantages, and I’m happy with both of them.

Keeping the placeholder visible on focus… wait a sec. Wasn’t that what we developed already? The outcome of this was that we threw all the custom handling out of the code and used the plain and simple [placeholder] attribute. As well as a label informing us about what should be entered, we can also display an example to the user. By moving on in their release cycles, the browsers supported ways of changing the placeholder style.

/*
 * Safari has kept the placeholder visible and the input focused since version 6
 * and since version 17 in Chrome (guessing from the WebKit version 535.11
 * in which this change was introduced)
 */
/* Safari 5+ (3.1+ lacking) / Safari iOS 3.2+ / Chrome 4+ */
::-webkit-input-placeholder {
  color: #a9a9a9;
}
 
:focus::-webkit-input-placeholder {
  opacity: 0.8;
}
 
 /* IE 10 */
:-ms-input-placeholder {
  color: #a9a9a9;
  opacity: 0.8;
}
 
/*
commented out because IE10 hides the placeholder when focused
:focus:-ms-input-placeholder {
  color: #a9a9a9;
  opacity: 0.5;
}
*/
 
/* Firefox 19+ (Gecko 19+) */
::-moz-placeholder {
  color: #a9a9a9;
  opacity: 0.8;
}
 
:focus::-moz-placeholder {
  opacity: 0.7;
}
 
/*
 * Firefox has kept the placeholder visible and the input focused since version 15
 *
 * http://www.mozilla.org/en-US/firefox/15.0/releasenotes/buglist.html
 * https://bugzilla.mozilla.org/show_bug.cgi?id=673873
 */
/* Firefox 4 - 18 (Gecko 2 - 18) */
input:-moz-placeholder,
:-moz-placeholder {
  color: #a9a9a9;
  opacity: 0.8;
}
 
input:focus:-moz-placeholder,
:focus:-moz-placeholder {
  color: #a9a9a9;
  opacity: 0.5;
}

And of course the markup is markup we love. :)

  <input type="text" name="foo" placeholder="bar" size="10">
  <br>
  <textarea name="foo_text" placeholder="bar text" cols="10" rows="4"></textarea>

This is just an example (the styles shown above are not applied):

As time goes by even a specification changes. The current HTML5.1 nightly specification (Editor’s Draft 15 April 2013) states:

User agents should present this hint to the user [...] when the element’s value is the empty string or the control is not focused (or both) [...].

(so they also kind of adopted as well in a way because it’s not explicitly forbidden to show the placeholder if the input is empty and focused)

We decided to only write a fallback for Internet Explorer 8 and 9. Both of them are still used widely. We’re checking IEs whether the placeholder attribute is supported or not.

  // we already excluded IE lower than or equal 7 at this point
  if (!("placeholder" in document.createElement("input"))) {
    // handle fallback case
    // which is summarized by an element behind the input. the tricky
    // part about this is that an input with a transparent
    // background and an element with text behind can cause a
    // well I would say "event trap"
    // a good explanation can be found here:
    // http://blog.rednael.com/CommentView,guid,518600bc-c062-4657-bd25-5aae64d32c1d.aspx
  }

Text areas are only partially supported in Opera 11.0 – 11.5 and Safari 3.1 – 4.0, but this is acceptable. (People, update your browsers!) Fun fact: iOS Safari has full support starting in version 3.2. ;-)

Conclusion

Browsers and specifications evolve and so does XING. While browser vendors started to implement the placeholder, we chose another way by introducing a custom user experience. Some of the browser vendors decided this is the direction to go, so the only thing that needs to be done is to reduce the markup and set up the JavaScript logic for IE only. Besides saving bytes (when downloading), this also saves a lot of event listeners and DOM accesses while the page is running and the user wants to interact.

Custom solutions are never easy to build so we should always think about whether it is worth it from more than one perspective.

List of references

http://devblog.xing.com/frontend/placeholder-custom-solution-vs-native-html5-feature/

http://stugreenham.com/articles/changes-to-the-html5-placeholder-behaviour/

http://www.mozilla.org/en-US/firefox/15.0/releasenotes/buglist.html

https://bugzilla.mozilla.org/show_bug.cgi?id=673873

http://www.w3.org/html/wg/drafts/html/master/forms.html#the-placeholder-attribute

http://caniuse.com/#search=placeholder