mirror of
https://github.com/MarshalX/telegram-crawler.git
synced 2024-11-29 19:53:17 +01:00
267 lines
18 KiB
HTML
267 lines
18 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<title>Telegram Support Force</title>
|
|
<meta name="twitter:card" content="summary"></meta>
|
|
<meta property="og:title" content="Feature Philosophy">
|
|
<meta property="og:description" content="This manual is intended for volunteers of the TSF, but anyone else is free to take a look as well.
|
|
There's a million things…">
|
|
|
|
<link rel="icon" type="image/svg+xml" href="/img/website_icon.svg?4">
|
|
<link rel="apple-touch-icon" sizes="180x180" href="/img/apple-touch-icon.png">
|
|
<link rel="icon" type="image/png" sizes="32x32" href="/img/favicon-32x32.png">
|
|
<link rel="icon" type="image/png" sizes="16x16" href="/img/favicon-16x16.png">
|
|
<link rel="alternate icon" href="/img/favicon.ico" type="image/x-icon" />
|
|
<script>document.cookie="stel_dt="+encodeURIComponent((new Date).getTimezoneOffset())+";path=/;max-age=31536000;samesite=None;secure"</script>
|
|
|
|
<link href="//telegram.org/css/font-roboto.css?1" rel="stylesheet" type="text/css">
|
|
<link href="//telegram.org/css/bootstrap.min.css?3" rel="stylesheet">
|
|
<link href="//telegram.org/css/bootstrap-extra.css?2" rel="stylesheet">
|
|
<link href="/css/telegram.css?236" rel="stylesheet">
|
|
<link href="/css/tsf.css?7" rel="stylesheet">
|
|
<link href="/css/jquery-ui.min.css?1" rel="stylesheet">
|
|
<link href="/css/health.css?136" rel="stylesheet">
|
|
<link href="/css/tchart.min.css?10" rel="stylesheet">
|
|
<link href="/css/billboard.css?17" rel="stylesheet">
|
|
|
|
</head>
|
|
<body class="emoji_image no-transition">
|
|
|
|
<div id="aj_progress" class="progress-bar"></div>
|
|
|
|
<div id="aj_content"><div class="tr-container">
|
|
<header>
|
|
<div class="container">
|
|
<div class="header-wrap">
|
|
<div id="header-panel" class="header-panel">
|
|
<div class="header-auth">
|
|
<div class="header-auth-item"><a class="header-search-btn"></a></div><div class="header-auth-item"><a class="header-auth-link login-link" href="/auth">Login</a></div>
|
|
</div>
|
|
<div class="header-breadcrumb header-breadcrumb-simple">
|
|
<ol id="breadcrumb" class="header-nav breadcrumb"><li><a href="/">Telegram Support Force</a></li></ol>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</header>
|
|
<main class="container">
|
|
<nav class="tr-menu">
|
|
<div class="tr-menu-section">
|
|
<div class="tr-menu-header">
|
|
<div class="tr-menu-header-label">Resources</div>
|
|
</div>
|
|
<ul class="tr-menu-items"><li>
|
|
<a class="tr-menu-item" href="/">
|
|
<span class="nav-label">Introduction</span>
|
|
</a>
|
|
</li><li class="active">
|
|
<a class="tr-menu-item" href="/manuals">
|
|
<span class="nav-label">Manuals</span>
|
|
</a>
|
|
</li></ul>
|
|
</div>
|
|
|
|
|
|
</nav>
|
|
<section class="content clearfix">
|
|
<section class="tr-content"><div id="dev_page_content_wrap" class=" ">
|
|
<div class="dev_page_bread_crumbs"><ul class="breadcrumb clearfix"><li><a href="/" >Telegram Support Initiative</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/manuals" >Manuals</a></li><i class="icon icon-breadcrumb-divider"></i><li><a href="/manuals/feature_philosophy" >Feature Philosophy</a></li></ul></div>
|
|
<h1 id="dev_page_title">Feature Philosophy</h1>
|
|
|
|
<div id="dev_page_content"><blockquote>
|
|
<p>This manual is intended for volunteers of the <a href="/">TSF</a>, but anyone else is free to take a look as well.</p>
|
|
</blockquote>
|
|
<p>There's a million things you could do, and yet you can't do them all at once. Building a messenger, as anything else, is about making the right choices. This manual covers the factors we always keep in mind when considering new features. This text serves as a companion to our (internal) <a href="https://trello.com/b/TgdZ0YI6">user suggestions board</a> where you can find more detailed estimates on the likelihood for particular features to be added to Telegram.</p>
|
|
<h4><a class="anchor-link" href="#determining-priority"><i class="anchor-icon"></i></a><a class="anchor" name="determining-priority"></a>Determining priority</h4>
|
|
<p>The formula to determine which feature gets implemented first is pretty straightforward:</p>
|
|
<pre><code>(relevance for the project + UX improvement) / (added complexity x speed impact x development time)</code></pre>
|
|
<p>This formula is everything you really need, although I will describe the components in greater detail below.</p>
|
|
<hr>
|
|
<h4><a class="anchor-link" href="#1-relevance"><i class="anchor-icon"></i></a><a class="anchor" name="1-relevance"></a>1. Relevance</h4>
|
|
<p>Telegram is a <strong>mass market messenger</strong> with a focus on <strong>speed</strong> and <strong>security</strong>. A good product needs to be consistent, so every feature we add must be relevant to these core aspects. And they are all equally important, we can't give too much preference to any one of them. We must keep all the aspects <strong>in harmony</strong>.</p>
|
|
<blockquote>
|
|
<p>E.g. any security-related feature we introduce must allow us to stay comprehensible for the masses and just as fast. Same with mass market features, we must stay as secure as possible when introducing them.</p>
|
|
</blockquote>
|
|
<h4><a class="anchor-link" href="#2-ux-improvement"><i class="anchor-icon"></i></a><a class="anchor" name="2-ux-improvement"></a>2. UX improvement</h4>
|
|
<p>While we love our users very much, we are not building our messenger to please individuals. This is a mass market messenger, and we cater to the masses. This automatically means two things:</p>
|
|
<ul>
|
|
<li>Any new feature must be useful to at least 5% of the <strong>users</strong> (and 50% is better,)</li>
|
|
<li>Any new feature must be useful at least 5% of the <strong>time</strong> (and 50% is better)</li>
|
|
</ul>
|
|
<blockquote>
|
|
<p>So ask yourself: Will <strong>tens of millions</strong> of people around the world use this feature more than once a month?</p>
|
|
</blockquote>
|
|
<p>Exotic features may look fancy and bring in good press, but they are wasteful. They don't contribute much to overall user experience (since they are used so rarely by so few users) — but they cost you time, developer resources and result in increasing complexity of the interfaces. Introducing a seemingly harmless exotic feature can sometimes result in damaging the UX instead:</p>
|
|
<h4><a class="anchor-link" href="#3-complexity"><i class="anchor-icon"></i></a><a class="anchor" name="3-complexity"></a>3. Complexity</h4>
|
|
<p>A good user interface is about minimizing choice and diversity. For example, 90% of Telegram is just 5 screens: list of chats, messages in a chat, profile screen, list of contacts, settings screen. The ultimate goal of a good UI is to rely on as few entities, options and settings as possible. </p>
|
|
<p>Yes, <strong>settings are evil</strong> because they fragment the user experience. Each new setting increases the complexity of your app and steepens the learning curve. You cannot escape choices by just offering settings and pushing the decisions you must make over to the user. The more settings you get, the more tuning your user will need to do to arrive at usability.</p>
|
|
<p>We don't have the luxury of the users' attention and nobody spends an afternoon setting up and studying how an app works. So everything we have must be <strong>instantly clear</strong> to anyone. Ideally. This may not be exactly the case even now, but the important thing is — we must not make it worse. Extra settings and options are a necessary evil sometimes, but generally we should find ways of avoiding them by providing the one true path out of the box.</p>
|
|
<h4><a class="anchor-link" href="#4-speed"><i class="anchor-icon"></i></a><a class="anchor" name="4-speed"></a>4. Speed</h4>
|
|
<p>As a mass market messenger Telegram must successfully compete with players that provide fewer encryption options, use weaker algorithms, or neutralize their own encryption for the sake of usability and speed. Thanks to certain breakthroughs in MTProto's design we are above our competition in terms of speed staying more secure at the same time. But we must always be on our guard and take care that the features we introduce do not slow us down too much.</p>
|
|
<h4><a class="anchor-link" href="#5-development-resources"><i class="anchor-icon"></i></a><a class="anchor" name="5-development-resources"></a>5. Development resources</h4>
|
|
<p>Telegram is a small band of very focused developers. We only have one specialist per app — and yet we usually try to update our apps at least once a month, ideally twice. In order to achieve this pace, we must choose wisely what we implement. Some of our plans are affected by the current Telegram infrastructure: certain things are easier to introduce, while other require massive changes in the server-side code, API or the MTProto protocol itself.</p>
|
|
<hr>
|
|
<h4><a class="anchor-link" href="#to-sum-up"><i class="anchor-icon"></i></a><a class="anchor" name="to-sum-up"></a>To sum up</h4>
|
|
<p>On the whole, it is better to be rich and healthy than poor and sick. In an ideal universe this means only implementing things that are <strong>relevant to the project</strong> and to the <strong>masses</strong>, add <strong>zero complexity</strong> to the interface, have <strong>positive effect on app speed</strong>, while costing nothing in terms of <strong>time</strong> and <strong>developer effort</strong>.</p>
|
|
<p>In a more real world this means that we usually wouldn't do things that are irrelevant to the project, or highly exotic, or introduce too much complexity, or slow Telegram down too much, or require too much time and effort (when that same time and effort could be used to make several other things happen, possibly with a higher UX impact).</p>
|
|
<p>That said, every now and then we do the impossible or the unheard of. Being too rational all the time would be boring, right? Fracture holy chipmunks.</p>
|
|
<hr>
|
|
<h3><a class="anchor-link" href="#feature-philosophy-faq"><i class="anchor-icon"></i></a><a class="anchor" name="feature-philosophy-faq"></a>Feature Philosophy FAQ</h3>
|
|
<h4><a class="anchor-link" href="#q-so-who-decides"><i class="anchor-icon"></i></a><a class="anchor" name="q-so-who-decides"></a>Q: So who decides?</h4>
|
|
<p>We monitor our users' reactions closely via our support channels, twitter and store reviews. But in order to maintain consistency in the product, the ultimate power of decision must lie in the hands of one person. In Telegram's case this person is <a href="http://en.wikipedia.org/wiki/Pavel_Durov">Pavel Durov</a>, his vision and experience got us this far — and will hopefully get us much further.</p>
|
|
<h4><a class="anchor-link" href="#q-why-not-let-the-people-decide"><i class="anchor-icon"></i></a><a class="anchor" name="q-why-not-let-the-people-decide"></a>Q: Why not let the people decide?</h4>
|
|
<p>User requests are an essential part of Telegram's development. But uncontrolled democratic processes in software development can be dangerous. Unfortunately, vocal minorities don't always properly represent silent majorities. And those silent majorities in turn only become vocal when changes in the system begin hurting them. All of this can result in erratic behavior: adding features just to remove them 6 months later, introducing conciliatory settings. This is usually followed by the slow and inevitable demise of the project.</p>
|
|
<p>So in Telegram we've opted for a well informed autocratic approach.</p>
|
|
<h4><a class="anchor-link" href="#q-x-has-this-feature-why-don-39t-we"><i class="anchor-icon"></i></a><a class="anchor" name="q-x-has-this-feature-why-don-39t-we"></a>Q: X has this feature! Why don't we?</h4>
|
|
<p>Many of our competitors have features that we don't have — or don't have yet. It is important to understand that they have those features for a reason. And this reason is not necessarily relevant for Telegram.</p>
|
|
<blockquote>
|
|
<p>A good example of this is the 'delivered to device' status that some of the WhatsApp fans ask us to introduce. This status would be useless here, Telegram being a cross-platform cloud messenger. I'm logged in on my PC at home and on my phone. So what does it matter to you that my PC downloaded the message while I'm stuck on a mountain with no network coverage on my phone?</p>
|
|
</blockquote>
|
|
<p> But whatever the situation may be right now, there is always a chance that things will change in the future. So never be radical and never burn your bridges. We're constantly looking for meaningful ways to improve Telegram. This means that any suggestion has a chance of becoming reality — at some point in the future, in some way.</p>
|
|
<hr>
|
|
<h3><a class="anchor-link" href="#more-tsf-manuals"><i class="anchor-icon"></i></a><a class="anchor" name="more-tsf-manuals"></a>More TSF manuals</h3>
|
|
<p><div class="dev_page_nav_wrap"></p>
|
|
<ul>
|
|
<li><a href="/">TSF Manifesto</a></li>
|
|
<li><a href="/manuals/bios">BIOS</a></li>
|
|
<li><a href="/manuals/answering_questions">Answering questions</a></li>
|
|
<li><a href="/manuals/bugs">Bug handling and troubleshooting</a></li>
|
|
<li><strong><a href="/manuals/feature_philosophy">Feature Philosophy</a></strong> (you are here)</li>
|
|
</ul>
|
|
<p></div></p>
|
|
</div>
|
|
|
|
</div></section>
|
|
</section>
|
|
</main>
|
|
</div><div class="popup-container login-popup-container hide" id="login-popup-container">
|
|
<div class="popup">
|
|
<div class="popup-body">
|
|
<section>
|
|
<h2>Log In</h2>
|
|
<p>Log in here to access your TSF stats. Please enter your <b>phone number</b> in the <a target="_blank" rel="noopener" href="https://telegram.org/faq#login-and-sms">international format</a> and we will send a confirmation message to your account via Telegram.</p>
|
|
|
|
<form id="send-form" class="login-form">
|
|
<div class="form-group">
|
|
<input type="tel" class="form-control tr-form-control input-lg" id="phone-number" placeholder="+12223334455" autocomplete="off"/>
|
|
</div>
|
|
<div class="popup-buttons">
|
|
<a class="btn btn-link btn-lg login-cancel-btn">Cancel</a><button type="submit" class="btn btn-link btn-lg">Next</button>
|
|
</div>
|
|
</form>
|
|
|
|
<div id="login-form" class="hide">
|
|
<div class="form-group">
|
|
<span class="form-control tr-form-control input input-lg input-disabled"><strong id="phone-number-field"></strong> (<a class="login-back" href="/auth">Incorrect?</a>)</span>
|
|
<p class="help-block dots-animated">We've just sent you a message.<br/>Please confirm access via Telegram</p>
|
|
</div>
|
|
<div class="popup-buttons">
|
|
<a class="btn btn-link btn-lg login-cancel-btn">Cancel</a><a class="btn btn-link btn-lg login-back">Back</a>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
</div>
|
|
</div>
|
|
</div></div>
|
|
<script src="//telegram.org/js/jquery.min.js?1"></script>
|
|
<script src="//telegram.org/js/bootstrap.min.js"></script>
|
|
<script src="//telegram.org/js/main-aj.js?68"></script>
|
|
<script src="/js/main.js?47"></script>
|
|
<script src="/js/tsf.js?3"></script>
|
|
<script src="/js/jquery-ui.min.js?1"></script>
|
|
<script src="/js/tchart.min.js?18"></script>
|
|
<script src="/js/billboard.min.js?1"></script>
|
|
<script src="/js/stats.js?18"></script>
|
|
|
|
<script>ajInit({"version":805,"apiUrl":"\/api?hash=telegram-crawler","unauth":true});</script>
|
|
<script id="aj_script">Aj.onLoad(function(state) {
|
|
function requestConfirmation(event) {
|
|
event && event.preventDefault();
|
|
var phone = $('#phone-number').val();
|
|
$.ajax({
|
|
type: 'POST',
|
|
url: '/auth/request',
|
|
data: {
|
|
phone: phone
|
|
},
|
|
success: function(result) {
|
|
$('#phone-number-field').text(phone);
|
|
$('#send-form').addClass('hide');
|
|
$('#login-form').removeClass('hide');
|
|
checkAuth(result.temp_session);
|
|
},
|
|
error: function(xhr) {
|
|
showAlert(xhr.responseText || 'Server error');
|
|
},
|
|
dataType: 'json'
|
|
});
|
|
return false;
|
|
}
|
|
function cancelConfirmation(event) {
|
|
event && event.preventDefault();
|
|
$('#phone-number-field').text('');
|
|
$('#send-form').removeClass('hide');
|
|
$('#login-form').addClass('hide');
|
|
$('#phone-number').focus();
|
|
clearTimeout(window.authTimeout);
|
|
return false;
|
|
}
|
|
function checkAuth(temp_session) {
|
|
clearTimeout(window.authTimeout);
|
|
window.authTimeout = setTimeout(function doCheckAuth() {
|
|
$.ajax({
|
|
type: 'POST',
|
|
url: '/auth/login',
|
|
data: {
|
|
temp_session: temp_session
|
|
},
|
|
success: function(result) {
|
|
if (result) {
|
|
location.reload();
|
|
} else {
|
|
checkAuth(temp_session);
|
|
}
|
|
},
|
|
error: function (xhr) {
|
|
showAlert(xhr.responseText || 'Server error');
|
|
},
|
|
dataType: 'json'
|
|
});
|
|
}, 700);
|
|
}
|
|
$('#login-popup-container').on('popup:open', function() {
|
|
$('#phone-number').focus();
|
|
});
|
|
$('#login-popup-container').on('popup:close', function() {
|
|
cancelConfirmation();
|
|
if (location.pathname == '/auth') {
|
|
window.history && history.replaceState(null, null, '/');
|
|
}
|
|
});
|
|
$('#login-popup-container #send-form').on('submit', requestConfirmation);
|
|
$('#login-popup-container .login-cancel-btn').on('click', function(e) {
|
|
e.preventDefault();
|
|
closePopup('#login-popup-container');
|
|
});
|
|
$('#login-popup-container .login-back').on('click', cancelConfirmation);
|
|
$('.login-link').on('click', function(e) {
|
|
e.stopImmediatePropagation();
|
|
e.preventDefault();
|
|
openPopup('#login-popup-container');
|
|
});
|
|
});
|
|
Aj.onUnload(function(state) {
|
|
$('#login-popup-container').off('popup:open');
|
|
$('#login-popup-container').off('popup:close');
|
|
$('#login-popup-container #send-form').off('submit');
|
|
$('#login-popup-container .login-cancel-btn').off('click');
|
|
$('#login-popup-container .login-back').off('click');
|
|
$('.login-link').off('click');
|
|
});
|
|
</script>
|
|
<script>Aj.pageLoaded();</script>
|
|
|
|
</body>
|
|
</html>
|
|
|