Development Of Web Cards For Social Networks In Regional Languages

DEVELOPMENT OF WEB CARDS FOR SOCIAL NETWORKS IN REGIONAL LANGUAGES

A TERM PAPER REPORT Submitted in partial fulfillment of requirements to ACHARYA NAGARJUNA UNIVERSITY For the award of the degree B.Tech in CSE By V.A.Naveesha

Y6CS409

R.Praveen

Y6CS460

N.Anisha

Y6CS406

D.N.Teja

Y6CS444

OCT 2009 BAPATLA ENGINEERING COLLEGE (Approved by A.I.C.T.E) (Affiliated to Nagarjuna University) BAPATLA

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING BAPATLA ENGINEERING COLLEGE (Approved by A.I.C.T.E) (Affiliated to Acharya Nagarjuna University) BAPATLA

BONAFIDE CERTIFICATE Certified that this project work titled “Development of Web Cards for Social Networks in Regional Languages” is the bona fide work of Mr. /Ms.: Batch13 (V.A.Naveesha (Y6CS409), R.Praveen (Y6CS460), N.Anisha (Y6CS406), D.N.Teja (Y6CS444)) who carried out the work under my supervision, and submitted in partial fulfillment of the requirements for the award of the degree, BACHELOR OF TECHNOLOGY IN COMPUTER SCIENCE & ENGINEERING, during the year 2009 - 2010.

B.Suresh Kumar

Dr. N.Sudhakar

(Asst. Prof, Dept of CSE)

(Prof, Head, Dept of CSE)

ACKNOWLEDGEMENT

“The successful completion of any task would be incomplete without mentioning the people who made it possible and whose constant encouragement secured as our success” At the outset of presenting out project work, we would like to acknowledge the help render by various personal in this project. We express our sincere thanks to our guide and coordinator Mr.B.Suresh Kumar who helped us by giving constructing suggestions and valuable encouragements. We have immense pleasure in expressing our heartfelt thanks to Prof N.Sudhakar, Head of the Department, Computer Science and Engineering, for his valuable guidance, encouragement and unreserved cooperation at each stage to complete our project work successfully. We would like to take this opportunity to thank our beloved Principal, Prof. K. Lakshmi Prasad, for providing a great support for us in completing our project and giving us the opportunity of doing the project. Last but not the least we would like to express our acknowledgement to all our staff members, technical assistants and students for their valuable help and coordination in the accomplishment of our project.

V.A.Naveesha R.Praveen N.Anisha D.N.Teja

TABLE OF CONTENTS

Chapter No

Title Abstract

1

Introduction

2

Requirements Specification a. Introduction i. Purpose ii. Scope iii. Objective b. Requirements i. User Requirements ii. Software Requirements iii. Hardware Requirements iv. Functional Requirements

3

Analysis a. Existing System b. Proposed System c. Technical Analysis d. Functional Model i. Use case Model e. Object Model i. Class Diagrams f. Dynamic Model i. Activity Diagrams

Page No

4

System Design a. Introduction i. Purpose ii. Design Goals b. Software System Overview i.

Component Diagram

ii.

Deployment Diagram

5

Conclusion

6

Screenshots

7

References

DEVELOPMENT OF WEB CARDS FOR SOCIAL NETWORKS IN REGIONAL LANGUAGES

ABSTRACT This application provides user with some templates for greeting our friends which can be modified as per the user desire. The user is provided with the option of using his regional language, Telugu, if interested. Application enables user in modifying the layout of the greeting, colors, edit messages, and add effect. After the user is done with designing of the card, it can be scrapped to either a single or multiple friends. Most of the social networking sites now support the OpenSocial specification for the development of applications. OpenSocial is a set of common APIs for building social applications across many websites. The OpenSocial API specification can be implemented by any social network including but not limited to Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, MySpace, Ning, Oracle, orkut, Plaxo, Salesforce.com, and XING. OpenSocial platform implementation turns it into a social platform and then allows third party applications to run on it. OpenSocial helps these sites share their social data with the web. Applications that use the OpenSocial APIs can be embedded within a social network itself, or access a site's social data from anywhere on the web.

FEATURES  Regional Language support.  Place user desired messages in the greeting.  Modify the colors, add effects to greeting.  Can be easily sent to friends.

Chapter 1 INTRODUCTION

OpenSocial is a set of common APIs for building web-based applications across many social network websites. Applications implementing the OpenSocial APIs will be interoperable with any social network system that supports them. The OpenSocial API specification can be implemented by any social network if taken some time in adopting it. OpenSocial implementation turns the networking site into a social platform and then allows third party applications to run on it. Most of the social networking sites now support the OpenSocial specification for the development of applications. The existence of this single programming model helps both developers and websites. First, developers only have to learn the APIs once in order to build applications that work with any OpenSocial-enabled website. Second, because any website can implement OpenSocial, developers have a broad distribution network to reach users. Websites also benefit by engaging a much larger pool of third party developers than they could without a standard set of APIs.

About Project In this project we make use OpenSocial API and develop an application which can be used in any OpenSocial container. For the development of OpenSocial application JavaScript and HTML are the basic languages used. In addition to that other server-side programming languages like PHP, Ruby, Python etc., can also be used. The main idea behind our application is to develop a user friendly web cards application which enables the user in designing their own cards by making use of the templates provided. The striking feature of the application is to provide support for regional languages. Unlike the e-mail clients where all the contacts need to be saved, in a social network it is so easy to manage the contacts. Hence, whenever a web card needs to be posted to a user’s friend, it can be easily done. This encourages the user to preferably use this application. The analysis regarding the design and technical aspects of this application have be done in different perspective and are presented in this book.

Chapter 2 REQUIREMENTS SPECIFICATION

A. INTRODUCTION i. Purpose The basic purpose is to design application for gifting web cards in a social network site. In order to enhance the user satisfaction it is provided with several different features. The Striking feature of this application is that it provides the facility of using regional languages like Telugu. Unlike a normal web card where the user is presented with a pre-designed card, here the user can make changes to the design of the card. The user will be able to change the colors of the background, small objects placed in the card, add effects to the card. The messages in the card can be edited by the user and finally embedded in the card. The application must provide a convenient procedure for sending the card to different friends of the user. Apart from using the OpenSocial API the application must also follow the specifications of the container, which may be having container specific rules which must be followed in order that the application is hosted on the server. The application must be presented with a user friendly GUI so that it stands apart from the several applications already present in any social network.

ii. Scope Earlier when the OpenSocial was not used every web application that is developed is limited to implementation in only the social network it was designed. But, later the evolution of OpenSocial API has brought significant changes on the developer side. It made the developer’s job a lot easier and application that is developed can be used any of the OpenSocial containers that support the same. Any social network site can be made OpenSocial container by following the procedure mentioned in the OpenSocial site. The Social network sites that support OpenSocial is increasing at rapid rate and their list can be found in the following link: http://wiki.opensocial.org/index.php?title=Main_Page.

iii. Objective The primary objective of this project is to develop an OpenSocial application that helps users in designing their own cards and posting them to different friends in their network. Another objective is to provide the facility of using regional languages in the messages that are embedded in the cards. Apart from this, in the developer’s perspective the application need to follow all the rules specified by the specific OpenSocial container. Considering the example of orkut, an application submitted by a developer is accepted by the orkut administrators only when it satisfies all the specifications.

B. REQUIREMENTS i. User Requirements User-interface requirements are those that will enable us to ensure that there is a good match between the system that is developed and both the users of that system and the tasks that they will undertake when using it. In order to build usability into the system from the outset, we need to gather the following types of information: 

Characteristics of the users who will use the system.



The tasks that the users undertake, including the goals that they are trying to achieve.



Situational factors that describe the situations that could arise during system use.



Acceptance criteria by which the user will judge the system.

For our project, the user-interface requirements are: 

User must be provided with features like editing the message in the card.



Language of the message must be able to change as per the user requirement.



Different images and effects used in the card must be able to change in the card whenever required.



Interface must provide a convenient way in sending the cards to different friends in a user network.



Application should provide necessary help wherever required.



The user interface should be efficient in both speed and use.

ii. Software Requirements Operating System

:

Windows XP or later.

Scripting Language

:

JavaScript.

Application Programming

:

OpenSocial API

:

Eclipse with OSDE plug-in.

:

Mozilla Firefox 3.0 or higher

Interface Integrated Development Environment (IDE) Browser

Development of OpenSocial application can be done in two different ways. One is to use IDE development tool including OSDE plug-in, other way is to develop the application using the sandbox provided by the container which wish to post the application. Development of application in former way is far more efficient for a developer. Any application that is developed is to be tested in the container. This can be done by getting signed up for the sandbox of the container. After the application is developed completely, it must be hosted on a web server and the URL must be provided to social network container.

iii. Hardware Requirements Considering the requirements for developing an OpenSocial application by using an IDE, the following are requirements that must be satisfied for a hassle free development. Hard disk

:

40 GB

RAM

:

128MB

Processor

:

Pentium IV

iv. Functional Requirements Functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish.

Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by nonfunctional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). How a system implements functional requirements is detailed in the system design. As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system. Typically, a requirements analyst generates use cases after gathering and validating a set of functional requirements. Each use case illustrates behavioral scenarios through one or more functional requirements. The crux of the requirement is the description of the required behavior, which must be clear and readable. The described behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements may be uncovered during the use case development. When this happens, the requirements analyst may create a placeholder requirement with a name and summary, and research the details later, to be filled in when they are better known. Functional requirements include the following: 

Descriptions of the processing that the system will be required to carry out.



Details of data that must be held in the system.

For our Project, the functional requirements are: 

Provide different templates for greeting.



Application provides tools for modifying the templates in order to change the colors, text in the card.



It is able to use regional language like Telugu.

Chapter 3 ANALYSIS

A. EXISTING SYSTEM The Existing Social network applications provide users with web cards which can be sent only in English and also they do not provide the facility of editing the web cards as per the necessity of the user. The pre-designed web cards must be used by the user whether the user completely likes the card or not. Existing applications also do not provide a convenient way to send the cards to their friends. All the ids of the friends must be listed. It would be better idea to provide facility for grouping the friends into categories and to send cards depending on the group. This feature will be very must useful as most of the times it happens that user needs to send to a particular group of his friends and so this seems to be a better idea.

B. PROPOSED SYSTEM In the proposed system the application provides the facility of using regional languages, so that they can present a pleasing web cards to their friends. The web cards can be modified with regards to the colors used effects in card and so on, according to the user’s desire. The user is provided with the facility of grouping their friends into categories.

C. TECHNICAL ANALYSIS OpenSocial applications use Google's gadget architecture but with extensions that provide programmatic access to social data within its container environment. Similar to gadgets, OpenSocial apps are hosted XML documents with HTML/JavaScript within their bodies. Social apps have most of the infrastructure of gadgets available to them but with a few minor exceptions. OpenSocial includes three core APIs for social software applications to access data and core functions on participating social networks. Each API addresses a different aspect:



One for People and Friends (people and relationship information)



One for Activities (publishing and accessing user activity information to others e.g. reading books, watching movies etc.)



One for Persistence (provides a storage mechanism to save and load data).

Considering the case of developing an OpenSocial application for the orkut container the following are the primary things need to be understood before starting to develop an application. An Orkut application is comprised of several parts, all of which combine to form a structured user experience. As you develop your application, we recommend this guide as both a checklist of components which should be utilized, as well as a means to understand the relationship between these components: 1. Application Directory 2. Directory Listing 3. My Applications 4. Left Navbar Link 5. Canvas View 6. Showcase View 7. Friend Updates

Application Directory The Orkut application directory provides a listing of all applications, making it a primary starting point for a user to browse and add applications.

Directory Listing The application directory contains directory listings for each application which provide a concise view of an application using a title, thumbnail image (120px wide, 60px tall) and brief text description (300 characters max). When a user clicks the "add application" button on a directory listing, the application is immediately added to the user's left navbar and profile page.

My Applications The my applications page is used to manage a user's existing applications, as well as provide an entry point for the application directory. Through my applications, a user can add an application by its URL, remove an application, and access the application directory.

Left Navbar Link Once an application is added, an icon and the first 13 characters of the application title appear in the user's left navbar. This links to the application's canvas view.

Canvas View The application's canvas view is the full-page view of an application, framed by Orkut's top and left navigation elements. With the canvas view, you can take advantage of

additional screen space to provide functionality beyond what a user might see in the showcase view. The canvas view can also span multiple pages, increasing the range and depth of features your application can provide.

Showcase View The Orkut profile page is a representation of a user, summarizing a user's identity, friends, communities, photos and more. On this page, applications have a showcase view that is smaller than the canvas view, but still useful in summarizing application information and providing a means for users to complete simpler tasks. Since a user's profile is visible to both the user and others, an application can have distinct views based on whether the viewer is the owner of the page. For all viewers, it is often good practice to allow your application's showcase view to serve as a means of selfexpression for the user. When the viewer is a friend, the showcase view is an important place to market your application by outlining the core experience your application provides.

Friend Updates Friend updates are a passive way for a user to view his/her friends' activities (i.e. Orkut's activity stream). As the user's friends update profile information, add videos and photos, or add new applications, the most recent updates appear in the "updates from your friends" section at the user's orkut homepage. Applications can utilize friend updates by posting information to a user's activity stream when a user adds or interacts with the application.

D. FUNCTIONAL MODEL A function model or functional model in systems engineering and software engineering is a structured representation of the functions, activities or processes within the modeled system or subject area. A function model, also called an activity model or process model, is a graphical representation of an enterprise's function within a defined scope. The purposes of the function model are to describe the functions and processes, assist with discovery of information needs, help identify opportunities, and establish a basis for determining product and service costs.

i. Use case Model

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted. Actor Generalization One popular relationship between Actors is Generalization/Specialization. This is useful in defining overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general actor. Use Case Relationships Three relationships among use cases are used often in practice. Include In one form of interaction, a given use case may include another. "Include is a Directed Relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case". Extend In another form of interaction, a given use case (the extension) may extend another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label "«extend»". Notes or constraints may be associated with this relationship to illustrate the conditions under which this behavior will be executed. Generalization In the third form of relationship among use cases, a generalization/specialization relationship exists. A given use case may have common behaviors, constraints and assumptions to the general use case, describe them once, and deal with it in the same way, except for the details in the specialized cases.

Here, in developing a web cards application by considering the different use cases and actors that take part in the application the use case diagram is made as follows.

Select type of Card (from Use Cases)

Select a particular Card (from Use Cases)

Owner

Administrator

(f rom Actors)

(f rom Actors)

<<extend>> Edit Message (from Use Cases)

<<extend>>

Select Language Modify Card (from Use Cases)

Edit Text Send Card (from Use Cases)

E. OBJECT MODEL i. Class Diagrams Class diagram in the Unified Modeling Language (UML), is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

F. DYNAMIC MODEL i. Activity Diagrams Activity diagrams are a loosely defined diagram technique for showing workflows of stepwise activities and actions, with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

start View all Cards

Select type of card

Select particular card

Edit Text

Select Language

Modify Card

Select Friends

Send Card

Chapter 4 SYSTEM DESIGN

A. INTRODUCTION i. Purpose The basic purpose of application is to provide a user friendly application for greeting your friends on a social network. Design can be modified as per the taste of the user. To build more catchy cards by using their own regional languages like Telugu.

ii. Design Goals The design is intended to provide the user a graphical interface to design the cards. It is intended to satisfy the functional and non-functional requirements of the application.

B. SOFTWARE SYSTEM OVERVIEW i. Component Diagram The component diagram's main purpose is to show the structural relationships between the components of a system. It shows the runtime structure of the system at the level of software components. Components are the modular parts of the system and are made up of groups of related objects that are hidden behind an external interface. A component diagram describes the organization of the physical components in a system. Basic Component Diagram Symbols and Notations are as follows. Component A component is a physical building block of the system. It is represented as a rectangle with tabs. Interface An interface describes a group of operations used or created by components. Dependencies Draw dependencies among components using dashed arrows.

User

Card

Send Card

Edit Card

ii. Deployment Diagram A deployment diagram in the Unified Modeling Language serves to model the physical deployment of artifacts on deployment targets. Deployment diagrams show "the allocation of Artifacts to Nodes according to the Deployments defined between them." Deployment of an artifact to a node is indicated by placing the artifact inside the node. Instances of nodes (and devices and execution environments) are used in deployment diagrams to indicate multiplicity of these nodes. For example, multiple instances of an application server execution environment may be deployed inside a single device node to represent application server clustering.

Web Cards Application Server

Application Database

Social network Site Server

Users Database

Chapter 5 CONCLUSION

The requirements and analysis for the development of web cards application have been made and are presented in this book. We are in the process of developing sample applications and hence get familiar with the OpenSocial API. We arrived at some conclusions regarding the best practices that must be adopted in order to develop applications in Orkut, which is our primary testing container. As the OpenSocial specification is under rapid development with lot of updates and modifications, it is very much required to get in touch with development group. By constantly monitoring the OpenSocial group in the Google groups we hope that we get on par with professional OpenSocial application developers. For the purpose of testing the applications, we got registered in the orkut sandbox and registered an application which we got hosted on a web server. In the development phase this testing application can be used to practice different concepts. Whenever changes are made to the application, it must be uploaded to the web server and hence it gets reflected in the sandbox environment. We have practiced the process of retrieving different information regarding a user like the bio-data of the user, user profile picture and so on. For the purpose of using regional languages we have found a free online typing tool for regional languages called Quillpad. This tool can be embed in the OpenSocial application and by making use of this we have made a sample application for just entering some text in Telugu and the screenshot of the same is being placed in following chapter. Further we need to work on embedding text onto image files and making modifications to properties of image files like changing the colors and effects of the image files. We need to develop a user friendly interface for the application and present some web cards templates. By making our best efforts we hope to develop an application following the standards of orkut networking site.

Chapter 6 SCREENSHOTS

Chapter 7 REFERENCES



Orkut developer Home - http://code.google.com/apis/orkut/docs/index.html



OpenSocial official website - http://www.opensocial.org/



OpenSocial Development Environment - http://code.google.com/p/opensocialdevelopment-environment/



OpenSocial JavaScript API Reference http://wiki.opensocial.org/index.php?title=JavaScript_API_Reference



Free Online Indian Language typing tool (Quillpad) - http://quillpad.in/