Несвесно губите новац, а ево и како

FacebookTwitterLinkedinEmail
30/08/2016
Несвесно губите новац, а ево и како
Извор: pixabay.com

Да ли ваш сајт (или апликација) прихвата све валидне називе домена и имејл адресе, правилно их складишти и обрађује?

Подесили сте у свом кафићу WiFi хотспот. Уколико се тражи од корисника да остави имејл адресу како би га регистровали, послали код за бесплатно повезивање на интернет и слично, може се десити да корисник не може да се повеже иако има сасвим валидну имејл адресу. Или, на вашем сајту за продају робе, корисник мора да остави имејл адресу, и то може да буде ограничавајући фактор. Или сте хотелијер и имате онлајн букинг, или сте агенција за продају авио карата, или имате било какву форму за пријаву на ваш онлајн сервис… због техничке застарелости ви губите кориснике, а самим тим и новац. Наравно, уколико сте на ово реаговали како је ваш систем нов и сасвим у реду, то ништа не значи. Систем је врло вероватно ипак застарео и не прихвата баш све кориснике.

Како, бре, застарео? Па нов је?

Проблем о коме причамо је сасвим једноставан. Ако корисник има на пример ћирилички назив домена који користи за имејл, сва је прилика да неће моћи да се региструје са тим имејлом на већину сервиса који се данас нуде на интернету.

Зато власници ових сервиса губе кориснике, а самим тим и новац. Kонтакт форме које се данас користе у највећем броју случајева не умеју да препознају ћириличку адресу е-поште као валидну. Без обзира на своје личне афинитете према ћирилици, губитак корисника је објективан и потребно је да се то исправи. 

Проблем превазилази употребу ћирилице и  јавља се код било које адресе е-поште која користи не-ASCII знаке (IDN). Ту спадају сви називи домена на кинеским, арапским, индијским и осталим писмима, а ни адреса е-поште као што је, на пример, krüger@nürnberg.de неће бити прихваћена као валидна због коришћења умлаута (“ü“).

Проблем се јавља и код енглеске латинице, али само у случају када се користе нови генерички домени. До сада смо навикли на употребу .com, .org, .net и сличних генеричких домена највишег нивоа. Међутим, већ неколико година се користе домени са екстензијама које могу да буду и дуже од 3 слова и који нису (били) уобичајени на интернету. Стручно се називају нови генерички домени највишег нивоа (енгл. New gTLD, New generic Top Level Domain). Такви су на пример: .xyz, .tech и слични. Иако није у питању IDN домен и нема не-ASCII знаке, велика је вероватноћа да форма која се испуњава на неком сајту неће прихватити адресу е-поште dusan@uasg.tech као валидну. Списак нових домена највишег нивоа можете наћи овде.

Као што се може наслутити, трећи и највиши ниво овог проблема јесте када имате нови генерички домен највишег нивоа али у нелатиничком писму, што је комбинација претходна два.

За решење овог проблема морате узети у обзир кориснички интерфејс, који мора да омогући унос оваквих адреса е-поште, а након тога се решава део саме валидације. Наравно, за ово је потребно да се позове произвођач те форме – програмер.

Да ли је то све?

Није.

Валидација (и прихватање) је први и основни део који је неопходно изменити како би ваш сервис радио исправно. Постоји још низ места где ваш систем треба „закрпити“. Програмер треба да завири дубоко „испод хаубе“ вашег система и да провери да ли овакве адресе е-поште могу уопште да се сачувају у бази корисника, да ли су поља у бази у таквом формату да омогућавају прихватање било какве адресе е-поште.

Такође, треба да погледа да ли део софтвера који обрађује податке из базе, уопште може да обради овакве адресе е-поште. И на крају, врло је важно да се не заборави и сам приказ резултата обраде, који врло често може да приказује погрешне резултате јер не разуме други алфабет осим енглеског. Дакле, пуно тестирања и рада на целом систему, и то на следећим нивоима: прихватање, валидација, смештање, обрада и приказивање.

И ту није крај?

Постоје контакт форме које траже и саме називе домена, па и ту може да настане идентичан проблем, на свим нивоима. А када се узме у обзир да ваш систем мора да буде прихватљив за све оперативне системе (било за мобилне, таблете, лаптоп или десктоп рачунаре) и програме на њима (било да сте их ви направили или су то прегледачи, имејл клијенти и слично), овај проблем прелази у ниво програмирања апликација.

Ево два могућа сценарија:

  1. Иако ваш онлајн сервис прихвата све адресе е-поште, ваша апликација (на пример, на Андроиду) их не прихвата, па је корисник принуђен да користи прегледач.
  2. Иако ваш онлајн сервис прихвата све адресе е-поште, прегледач (на пример, на iОS) их не прихвата или не постоји подршка на том оперативном систему.

Одлагање решавања једног наизглед безначајног проблема узима све више маха и да би проблем био решен потребно је да се спроведе темељно тестирање и изврше темељне преправке на различитим нивоима.

Управо ово је задатак радне групе која је формирана пре неколико година при ICANN-у, и која се већ дуже време бори са овим проблемом.

Да ли сте универзално прихватљиви?

Назив радне групе је Universal Acceptance Steering Group (UASG, Управљачка група за Универзално прихватање). Да бисмо објаснили о чему је реч, потребно је да разјаснимо појам Универзалног прихватања, а дефиниција гласи:

„Universal Acceptance is the state where all valid domain names and email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet-enabled applications, devices and systems.“ 

(Универзално прихватање је стање у ком су сви валидни називи домена и адресе е-поште прихваћени, потврђени, ускладиштени, обрађени и приказани правилно и доследно од стране свих интернет апликација, уређаја и система.)

У пракси, ова група тестира и контактира произвођаче софтвера и апликација како би се разрешили овакви проблеми и постигло Универзално прихватање. Више о овоме можете наћи на линку https://uasg.tech, а посебно могу да вам буду корисни текстови о томе како да постанете универзално прихватљиви.

Како би избегли сав даљи губитак новца и корисника, можете на сајту пронаћи форму где ћете пријавити проблем који треба да реши неки од глобалних произвођача софтвера, било да се ради о серверском или софтверу крајњег корисника. Уколико софтвер који сте ви направили није универзално прихватљив, није искључено да вас неки представник ове радне групе контактира са молбом да га измените у складу са препорукама са наведеног линка.

FacebookTwitterLinkedinEmail