Social Design Best Practices

If you're new to developing social applications, it can be difficult to immediately grasp how good applications facilitate fun and meaningful social experiences. To accelerate your learning, we've come up with a list of a few light-hearted recommendations around building good social applications. Not all of these "best practices" are necessary in every case, but they might spark thoughts about finding new users, keeping old ones, and leveraging the social graph for fresh content and viral spread.

1. Engage Quickly

Across containers, there's a common tendency for a user to take a chance on an unknown application, and shortly thereafter remove it if no immediate value is found. The lesson to be learned from this interaction is that first impressions really do matter, and it's necessary to engage the user quickly before attention is lost. To this end, we suggest you focus on the 30-second experience; before distracting the user with expert features or sending invites, slow down and give the user a simpler taste of what your application is about. Try the following:

• Show value and identity by making the purpose and core features of your application absolutely clear.
• Populate the application with fun or interesting content (especially content from friends) that makes for a browse-friendly experience.
• Make it easy for the user to add content, change settings and feel ownership of the application. This increases a user's desire to keep the application on his/her profile.

2. Mimic Look and Feel

Across OpenSocial containers there can be a lot of variation in the look and feel of pages and profiles. When designing your application, it can help to attempt consistency with the container UI by using similar fonts, tabs and buttons.

In cases where applications strive for stronger identity, it can be good to create a UI look and feel which is slightly distinct but still aesthetically strong to play on a user's tastes and need for self expression.

3. Enable Self Expression

The profile page in a container is often a representation of a user's identity, interests and tastes. From the perspective of the owner, it's a means for self expression and a starting point for exploring the social graph. From the perspective of viewers, it's a place to learn, communicate, and find shared interests. Applications best take advantage of the profile by enabling self expression through common interests around entertainment, brands and groups. Self expression is also enabled through specific forms of communication like gestures and gifts or conversations around special topics.

4. Make it Dynamic

Good social applications aren't only static badges of self expression; they dynamically change to provide an interesting experience across sessions. Change can be derived from the social graph as friends interact with the application to change its state. Change can also occur as the application internally generates new content. In both cases, the day-to-day changes can help to keep an application interesting and desired over time.

5. Expose Friend Activity

A particularly easy way to make an application dynamic and social is to record and present the activities of friends who are using the application. This could be thought of as an application-specific activity stream in which the news and updates of friends are always presented in the context of the application itself. From these activities, users become more aware of how others are using the application, driving increased use and change.

6. Browse the Graph

Exposing the activities of friends is one method among many for passively browsing the social graph. Users are often interested in low-effort interactions like viewing a friend's most recent activity, comparing content and choices, and indirectly interacting through their own activity. In supporting this style of interactions, it's essential to make it easy to browse what friends are doing. This is often achieved by linking names to a user's container profile or even creating application-specific user profiles which provide an overview of a user's activity and content.

Browsing the graph can also certainly extend beyond just friends. In some circumstances, it can be interesting to see and interact friends-of-friends, especially when drawn together by shared interests. Creating ways for a user to grow his/her social circle adds value to an application from the user's perspective by unearthing opportunities for new friends and content.

7. Drive Communication

Browsing friends' activities and content often flows well into conversation, creating an opportunity to develop deeper social interaction. In places where communication can happen, it's good practice to make the option explicitly available. This can be done in a more persistent, public manner through a comment system or sharing wall. It can also be done in private by linking into a container's messaging, email or instant messaging systems, or even through an internal communication layer like pokes or other simple gestures and messages.

8. Build Communities

A container's entire social graph is often huge, and even a user's immediate social circle might be too large for a user to easily track. By growing smaller communities and making them accessible, an application can provide rich and interesting functionality that enhances the overall social experience. There are three categories of communities which applications commonly build and utilize:

• Grouped relationships (e.g. best friends, family, classmates, etc.).
• Shared interests among a user's immediate social circle.
• Shared interests among the entire social graph.

9. Solve Real World Tasks

Self expression and communication are often fun and entertaining alone, but OpenSocial is also a platform that can be leveraged to solve real world tasks where the social graph assists us in making decisions. For example, while some might be prone to grab a book at random off the shelf, there are many who appreciate a good recommendation from a friend. With a variety of possibilities in entertainment and interests, it can be useful to facilitate meetings, purchases, recommendations, information management and learning to create a richer, more lasting experience across your application.

[시맨틱웹] 2.5. RDF가 무엇인가요?

아래 글은 본래 시맨틱웹 시리즈 FAQ 10에 들어가지 않지만, RDF의 개념도 설명하지 않고 시리즈 다음 편인 “꼭 RDF를 사용해야 하나요? XML 으로도 충분해 보이는데”를 한다는 것이 여러모로 무리인 것 같아 가볍게 RDF 개념을 설명하고 넘어가고자 한다. 사실대로 이야기 하자면, 아래 글 역시 시맨틱웹 카페에 있는 글인데, 시맨틱웹 자체에 대해 그리 깊지 못하게 이해하고 있을 때 쓴 글이라 구멍 투성이. (다시 읽어봤는데, 다행히도 틀린 것은 없는 것 같다. ㅋㅋ)

———————————————————–

RDF 개요

세상을 바라보는 방법은 여러가지가 있겠지만 그중 하나는 모든 것을 관계성에 근거를 두고 바라보는 것이다. 즉, 두 객체(object)를 놓고 봤을 때, 두 객체의 관계를 중심으로 하여 객체들을 연결을 시키는 것이다. 또 그 두 객체중 하나는 다른 어떠한 객체와 관계를 형성하고 그 관계를 따라 연결이 된다. 이런 식으로 계속 어느 객체, 또는 사물에 관게성을 줌으로서 계속 연속의 연속을 따라 나아가며 커다란 관계성의 그물을 형성하면 그것들 자체가 하나의 세계관이 될 수가 있다. 예를 들어보는 것이 아마 이해하는데 훨씬 도움이 많이 될 것이다:

1. 세종대왕은 조선의 왕이었다.
2. 세종대왕은 한글의 창시자이다.
3. 한글은 대한민국의 표준어이다.
4. 대한민국의 수도는 서울이다.
5. 서울은 1988년도 올림픽의 주최도시였다.
……

1번의 예에서는 “세종대왕”과 “조선”이 “~의 왕이다”라는 관계를 맺고 있으며 2번에서는 “세종대왕”과 “한글”이 “~의 창시자이다”라는 관계를 맺고 있음을 알 수 있다. 사실 우리 삶에서도 관계성에 기초에서 상황을 기술하는 경우가 허다한데, 가장 흔한 예 중의 하나는 “내 친구의 여동생의 남자친구의 할머니의 스승님은 1940년대 가장 활발하던 독립군 중 준 하나이였다” 것과 비슷한 사람의 관게를 통한 연결이다. 이런 식으로 정보나 데이터를 나타내는 형태를 흔히 일컬어 데이터 모델이라고도 한다.

RDF (Resource Description Framework) 은 월드와이드상에 존재하는 리소스에 관한 정보를 위에서와 같이 관계성에 근거를 두고 나타내 주는 형식 또는 언어이다. 좀더 정확하게는 (:주어 :서술어(predicate) :목적어) 의 형식을 이루는데, 1번의 예를 보면 “세종대왕”은 주어, “조선”은 목적어, “~는 ~의 왕이다”는 서술어임을 알 수 있다. 때로는 ‘리소스, 속성 (property), 리소스’ 라고 대신 표현을 하며 이 하나를 통틀어 문장이라고 부르기도 한다. 그러면 웹에서는 어떤 것들이 더 구체적으로 RDF를 사용할 수 있는가?

1. 김태우 — RunsBlogAt –> http://twlog.net
2. 김태우 — IsAdministratorOf –> http://cafe.daum.net/semanticweb
3. 김태우 — IsInterestedIn –> http://en.wikipedia.org/wiki/Web_2.0
……

이같은 예들은 끝없이 들 수 있다. 이것이 바로 RDF의 강점이다. 웹상의 어느 리소스들이나 위와 같이 단순한 형식으로 표현이 가능하다는 것. 리소스나 관계의 정의들도 단순히 “김태우”라는 어떠한 인물 또는 객체에 국한되는 것이 아니라, URI 로 대체함으로서 표현범위에 사실상 무한한 자유를 준다. 즉, 이제는 웹상의 모든 정보를 컴퓨터가 처리할 수 있는 정형화된 형태로 나타날 수 있다는 것이다.

그렇다면 시맨틱웹에는 RDF가 왜 그리도 중요할까?

총 700쪽이 넘는 백과사전 한권을 샀다고 해보자. 그리고 책을 산 사람은 어떠한 특별한 정보를 찾고 싶어한다. 그런데 불행히도 이 책에는 색인이 존재하지도 않고 책의 구성 또한 주제별도 아니고 가나다순도 아니라고 해보자. 이 사전에서 원하는 정보를 찾는 단 한가지 방법은 사실상 책을 모두 훑어 보는 것이다. 이럴 경우에는 원하는 것을 찾는데 소요되는 시간뿐이 엄청날 뿐만 아니라 때로는 모두를 훑어본 후에도 원한는 자료를 놓쳐서 찾지 못할 경우가 있다. 그 사전 자체에 관한 정보인 색인과 쪽수와 주제별 구성등은 우리가 원한는 정보를 찾는데 훨씬 수월하게 해준다. 이런 의미에서 이런 것들을 메타데이터(Metadata: ‘데이터에 관한 데이터’라는 뜻) 라고 하는데, 메타데이터가 있다는 것은 곧 정보의 검색과 추출, 처리등을 훨씬 신속정확하게 할 수 있다는 것을 뜻한다. 우리가 흔히 접하는 메타데이터의 예는 전화번호부, 도서목록, 영화평 등이 있다. 메타데이터에 관해서는 2장에서 더 자세히 공부하기로 한다.

RDF는 웹의 리소스에 관한 메타데이터를 표현할 수 있게 해주는 언어이다. 이제는 웹페이지내에 존재하는 모든 내용을 읽고 맞는 내용을 찾으려고 할 필요없이 (이것이 바로 현재 검색엔진들의 작동방식) 각자 페이지에 관한 요약 또는 필요점만 보고 정보를 찾아낼 수 있는 것이다. 그리하여 웹상의 모든 문서와 리소스에 관한 자료들을 컴퓨터들이 처리할 수 있는 일관된 형식으로 나타내고 결국 이로 인해서 시맨틱웹이 가능해지는 것이다. 이미 RDF는 널리 상용화가 되기 시작했으며 이는 모질라 브라우저에서 내부 데이터구조를 나타나는데 사용되고 있으며, 뉴스 사이트에서 많이 사용되는 RSS 1.0, 사람의 프로필과 일촌관계를 나타나는 FOAF에서 찾아볼 수 있다.

RDF를 이해한다면 시맨틱웹은 한 반 정도는 이해한다고 할 수 있다. 물론 이세상이 그렇게 간단하지만은 않은 것처럼, RDF도 좀더 많은 복잡한 기능을 요구하는 RDF 스키마와 온톨로지를 필요로 하게 된다. 그렇지만 시맨틱웹의 기초를 RDF와 같은 표준으로 성공적으로 잡았다는 사실 자체로 이미 W3C은 시맨틱웹의 현실화를 좀더 우리 앞에 바짝 이끌어 왔다고 할 수 있다. RDF가 시맨틱웹을 이해하는데 중요한 만큼 이 강좌를 좀더 복습하고 아래에 있는 링크들에서 RDF에 관한 더 자세한 공부도 많이 하기를 바란다. RDF에 관한 자세한 내용은 4장에서 배우기로 한다.