in the following description , numerous specific details are set forth regarding the systems and methods of the disclosed subject matter and the environment in which such systems and methods may operate , in order to provide a thorough understanding of the disclosed subject matter . it will be apparent to one skilled in the art , however , that the disclosed subject matter may he practiced without such specific details , and that certain features , which are well known in the art , are not described in detail in order to avoid complication of the disclosed subject matter . in addition , it will be understood that the embodiments described below are only examples , and that it is contemplated that there are other systems and methods that are within the scope of the disclosed subject matter . fig1 - 10 illustrate screenshots of an exemplary application according to an embodiment of the present disclosure . as labeled in fig1 , the illustrated screenshots are shown displayed on a mobile device 100 with a touch screen interface 102 . the mobile device 100 may be any sort of portable computing device , such as cellular phone , smart phone , tablet , laptop , or wearable computer . although the mobile device 100 is used in the exemplary application depicted in fig1 - 10 , it will be understood that aspects of applications according to embodiment of the invention may run in a variety of computing systems including desktop computer systems , online servers and cloud - based processing systems , and dedicated multi - processor systems as known in the art . fig1 is a screenshot of a splash screen . in some implementations the splash screen may be provided as a loading screen for when the application is first loading . the application may move from the splash screen to a login screen if the user is not logged into the application or to a main screen ( fig2 ) if the used is already logged in . some implementations may include multiple methods for user identification and authentication . the application can include a login screen that can direct the user to log in to an existing account on a third party site such as a social media site . in some implementations , additional options may be made available to a user , including signing in by other means or making an account specific to the system . one of ordinary skill will recognize a variety of existing methods in the art to allow a user to generate and maintain a unique user account for a service . for implementations on a personal device such as a mobile device , the application may maintain the login information such that the user is automatically authenticated and logged in on subsequent occasions . following a successful login , the application may navigate to a timeline screen . fig2 is a screenshot of a timeline screen 200 representing the history of votes the logged - in user has received from other users . as shown , the timeline screen 200 displays a tally of the votes received in each skill category on a particular day . different skills may be represented by skill icons 202 a and 202 b , and each skill category may have a name 204 . at least some of the users 206 who sent one or more of those votes may be listed as well . in some implementations , a user can select one of the entries in order to see further info about the votes associated with that entry , or can select a particular user icon 206 for more information on a particular user . in some implementations , the application on a mobile device may load a limited number of timeline entries from the application server when a request for the timeline is made on the device , which may be the most recent entries which are displayed when the timeline is first presented to the user . further timeline entries may only be requested and loaded if the user chooses to scroll past the initially - presented timeline entries , and may be requested in increments as necessary . alternatively , all or a larger subset of the timeline entries associated with the user may be stored on the mobile device for rapid access . from the timeline screen 200 , a user may be able to navigate to a players screen showing other users ( see fig3 ) by selecting the tab 208 , or may be able to open a sidebar menu by selecting a menu icon 210 . the menu icon 210 is shown on subsequent screens and , in some implementations , may be accessible from different screens within the application . fig3 illustrates a players screen 300 which shows the basic information of other users of the system . the information available on the screen 300 may include a profile picture 302 and user name 304 . in some implementations , the users displayed on the screen 300 may be restricted to other users in proximity to the user logged into the application . as shown in fig4 a , selecting a particular user on the screen 300 may cause a menu 400 to display , allowing the logged - in user to vote for a particular skill for another user . the menu 400 shows icons 402 representing different skill categories for which the logged - in user may vote for with respect to the selected user . although geometric shapes are used in fig4 a to represent the different skill categories , it will be understood that each skill category may be represented by a stylized badge or other icon which may include multiple colors and illustrated details beyond that shown in fig4 . an exemplary set of skill categories that may be provided for a user to vote on for a basketball implementation of the application may include : “ ace ”— scoring “ dimer ”— passing “ anchor ”— defense “ sniper ”— three - point shooting “ breaker ”— ball - handling “ savior ”— rebounding “ showstopper ”— blocking “ pickpocket ”— stealing “ posterizer ”— dunking other skill categories or combinations of skills may represented in different embodiments . for example , various fielding and batting categories may be made available for a baseball application . a chess application may include categories for openings , middle game , end game , and particular strategies such as gambits and defenses . a performance application may include categories for technical competence ( rhythm , pitch , form , etc .) as well as categories for artistic skill ( emotion , tone , showmanship , etc .). any sport , game , hobby , or other activity in which the judgment of other users as to an individual &# 39 ; s display of talent in specific categories can be represented by an embodiment of the present invention . when the logged - in user selects a particular skill for the particular player , as shown in fig4 b , a vote from the logged - in user to the selected user for the selected skill at the current time is sent to the application server . the application may automatically return to the players screen 300 , which may temporarily show a small icon 404 over the appropriate player &# 39 ; s profile entry to designate that a vote has been entered , as shown in fig4 c . fig5 a illustrates an example of a profile screen 500 which may provide a user with skill data for each of the user &# 39 ; s skills . the profile screen 500 can include the user &# 39 ; s user name 502 , a profile picture 504 , skill icons 506 , and scores 508 reflecting an achieved skill level for each of the skills . in some implementations , the profile screen 500 may also include icons representing a recent change in any skill for which the user has recently received additional votes . for example , the icon 510 showing a “+ 1 ” indicates that the user &# 39 ; s score in that skill has increased by 1 point due to 1 additional vote being made for that user in that skill . change icons such as the icon 510 may be used to indicate a change since the last time that a user has accessed the profile screen 500 , or may reflect any changes within a set period of time . in some implementations , the information may be presented differently depending on whether a mobile device is held upright in portrait orientation or sideways in landscape orientation . the landscape display ( not shown ) may in some implementations have the same information displayed in an alternate graphical format ( such as a chart or graph ), or may include different information . in other implementations , the landscape display may not differ significantly from the portrait display . some implementations may allow for votes to be transferred by means other than a centralized application server . for example , in some implementations , mobile devices in proximity to one another may be able to transfer profile information and / or votes directly between the devices using various methods of direct mobile - to - mobile communication ( such as shot - wavelength radio communications used in local area networks or a variety of protocols such as bluetooth ). where direct mobile - to - mobile communication is used to transfer profile information , votes , or other application data , the mobile applications involved in the transfer may also confirm the data transfer with a centralized application server at an appropriate time . server information regarding the current skill level of particular users may therefore be out of date if local votes have been received and not yet reported to the server . in some implementations , badge and trophy awards , or other achievements , may not be rewarded to a user until the relevant votes have been recorded and confirmed by the application server . as noted above , any of the screens may include a menu button providing the option to open to a menu sidebar 600 , as illustrated in fig6 . the sidebar 600 may include multiple buttons each of which navigates to a different application screen or application feature . as shown , button 602 leads to the timeline screen ( fig2 ), button 604 to a leaderboard screen ( fig8 ), button 606 to an invite screen for finding other users of the application ( not shown ), and button 608 to the players screen ( fig3 ). selecting the sidebar button again when the sidebar is already visible may cause the sidebar to close . in the embodiment represented by the present screenshots , a player &# 39 ; s skill level in each category is represented by a level allocated to each of the skills . from the profile screen 500 in fig5 , the user can select any of the individual skills to read an explanation of that particular skill . a screenshot of a sample skill explanation display 700 is shown in fig7 . tapping anywhere on display 700 returns the user to the profile screen 500 ( fig5 ). as a player receives votes in a particular skill , the player advances towards the next level in the skill . obtaining a new level in a skill after having received a set number of votes gives the player an additional badge . depending on the embodiment , any number of votes can be associated with successive badges . in one implementation , additional badges in a skill category can be earned with increasing number of points ; each badge level requires more additional points that the previous level to earn . as one particular example , a set of badges may be awarded when the user reaches 5 , 8 , 12 , 18 , 27 , 38 , 53 , 74 , 104 , 166 , 216 , 281 , 365 , 475 , 618 , 742 , 890 , 1068 , 1282 , 1538 , 1846 , 2215 , and 2658 total points in a particular skill category with no reference to other skills . other examples may include different numbers of votes to gain levels in different skills , representing the comparative popularity or difficulty of different skills . each particular badge for each particular skill may be given a different name . fig8 is an exemplary screenshot of a badge display 800 which may be shown each time a user receives a new badge from an increase in a skill level . in addition to the badges , certain score combinations may also result in rewards such as trophies . for example , trophies may be rewarded whenever a user &# 39 ; s total points in all skills reach a particular level . other trophies may be awarded when a particular set of skills , such as offensive or defensive skills , each reach a threshold level . fig9 illustrates an exemplary screenshot of a trophy display 900 which may be shown each time a new trophy is earned . in some implementations , an application may check for newly - earned trophies or badges periodically and display a presentation screen only when a user first checks in or when a user is on a certain screen . some embodiments may allow a user to choose whether and in what manner to receive a notification of a new trophy or badge . in some implementations , badges and trophies may have certain effects on the application or may be used exterior to the application to judge player skill level and experience . for instance , certain application features may only be unlocked once certain trophies or badges are earned . in some implementations , it may be possible for the application to arrange tournaments and send event invitations to users based on skill level , so that only those with badges and trophies at certain levels or in certain skills may be invited . fig1 a shows an illustrated screenshot of a leaderboard screen 1000 , which shows users ranked according to their highest score . by selecting a drop - down arrow 1002 , a user may be able to select whether to display overall leaders , or only recent leaders , from a drop - down menu 1004 as shown in fig1 b . in some implementations , the leaderboard may only list users that have been in proximity with the logged - in user ( that is , users for whom the logged - in user had the opportunity to vote ). the user &# 39 ; s own rank relative the leading users may also be included . in some implementations , customized leaderboards may be provided which include only a subset of users who meet particular criteria . for example , a leaderboard could include a set of users who have signed up to participate in a particular event . as another example , a leaderboard could include only those users with an established connection to the logged - in user , such as by means of a social networking site . in some implementations , a user may have some level of control over the contents of the user &# 39 ; s leaderboard . for example , a leaderboard may include by default all users that have been within proximity of the logged - in user , but the user may have the option to add and delete players from the leaderboard , which in turn will cause the leaderboard to display rankings for the modified pool of players . user &# 39 ; s may also be able , in some implementations , to limit the leaderboard display to only those with certain achievements , such as a skill level threshold or a requirement for specific badges or trophies . in some implementations , geographic and timing limits may be placed on voters to help avoid abuse of the system . as shown in the illustrated diagram of fig1 , a distance r may be used to determine an area 1100 in which a particular user , user 1 , can vote for other users and have other users vote for user 1 . users that are within the established area 1100 , such as users 2 - 5 , are visible to user 1 and eligible to be voted on . users outside the established area , such as users 6 and 7 , are not visible to user 1 and not eligible for voting . in some implementations , proximity may be determined by factors other than distance , such as signal strength or connectivity . as noted above , a variety of technologies exist to allow mobile devices to communicate locally , either directly ( by short - range radio , infrared , etc .) or through a local intermediary such as a wireless network router , access point , or cellular connection . in some implementations , devices on the same local network or devices able to connect directly may be considered in proximity without any particular distance constraint . fig1 is a flowchart representing one example of a method 1200 by which mobile devices may be used to identify players and record voting . as noted above , this may begin by determining that first and second devices , associated with first and second users respectively , are in proximity ( 1202 ). the assessment of proximity may be made by the mobile devices themselves or by an external system based on mobile location information . proximity parameters may be situational , may be user - set , or may be set generally for the system . based on the users &# 39 ; proximity , information about the second user is provided on the first mobile device . the amount of information provided about the second user may be limited to basic profile information such as user name and associated image , may include summary statistics such as overall level or number of badges / trophies , or may include detailed profile information including vote structure . any previous votes ( or , in some implementations , any votes more recent than a set threshold ) between the first user and the second user may also be provided as part of the information about the second user provided to the first user . in some implementations , the information presented may be limited by user - selected privacy settings associated with the second user &# 39 ; s profile , or may be determined by the presence or absence of a known relationship ( such as a social network connection ) between the users . once information about the second user appears on the first user &# 39 ; s device , the first user can vote for the second user in a particular skill ( 1206 ). the available skills may vary depending on a number of factors , including which skills have been “ unlocked ” for either user through a variety of means and the various profile information of either user . some skills may not be available for voting based on a level disparity between the users or because the first user has already voted that skill . after the first user has cast a valid vote for the second user in a particular skill , the second user &# 39 ; s profile may be updated based on that vote ( 1208 ). this may occur wherever the data structure of the second user &# 39 ; s profile exists , on one or more mobile devices and / or on a centralized application server . in addition to updating a vote total for the particular skill , updating the profile may also include checking to see if the vote has resulted in any new skill levels , badges , or trophies being available to the second user . in addition to updating the second user &# 39 ; s profile , the second user may be notified of the vote by the first user ( 1210 ). in some implementations , the information provided to the second user may include the identity of the voter and the time and location of the vote . notifications may in some circumstances be delayed , and multiple votes over a certain time period may be aggregated into a single notification . if the users are within the maximum distance , then the voter has the option of voting for the votee in a specific category , such as one of the skills illustrated in the previous figures . a record of the voter , votee , category , and a timestamp for the vote are sent to the application server , which records the vote and provides appropriate notifications to the votee &# 39 ; s device as well as updating the votee &# 39 ; s profile and statistics . there may also be a minimum time period before the voter can vote for that same votee again . fig1 is a block diagram representing a system 1300 in which votes may be cast . as shown , an application server 1302 may store information about each vote , including the identities of the votee and voter , the category of the vote ( that is , the particular skill being voted on ), and a timestamp representing when the vote is entered . the application server 1302 records a vote received from one user and mobile device 1306 b for a different user associated with a different mobile device 1306 a within the pre - defined maximum distance . the server 1302 records all of the data relevant to the vote ; each mobile device communicates with the application server by means of any appropriate protocol ( such as a rest api ). fig1 is a flowchart representing one method for updating user leaderboards . each time two users are identified as within a maximum distance , the system checks to see if the users are new to each other . if so , the encounter may be recorded with a timestamp , and the two users added to each other &# 39 ; s leaderboards . in one implementation , some of this processing may be performed by one or more of the users &# 39 ; mobile device applications ; in others , these steps are carried about by an application server or associated processing system . it is to be understood that the disclosed subject matter is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings . the disclosed subject matter is capable of other embodiments and of being practiced and carried out in various ways . also , it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting . as such , those skilled in the art will appreciate that the conception , upon which this disclosure is based , may readily he utilized as a basis for the designing of other structures , methods , and systems for carrying out the several purposes of the disclosed subject matter . it is important , therefore , that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the disclosed subject matter . although the disclosed subject matter has been described and illustrated in the foregoing exemplary embodiments , it is understood that the present disclosure has been made only by way of example , and that numerous changes in the details of implementation of the disclosed subject matter may be made without departing from the spirit and scope of the disclosed subject matter , which is limited only by the claims which follow .