Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP

Xây dựng Startup của bạn: Yêu cầu thay đổi việc lập kế hoạch

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Building Your Startup With PHP.
Building Your Startup: Advanced Scheduling Commands
Building Your Startup: Meetings With Multiple Participants

Vietnamese (Tiếng Việt) translation by Andrea Ho (you can also view the original English article)

Final product image
What You'll Be Creating

Hướng dẫn này là một phần của loạt bài Building Your Startup with PHP trên Envato Tuts+. Trong loạt bài này, tôi hướng dẫn bạn phát hành một startup từ khái niệm đến thực tế bằng cách sử dụng ứng dụng Meeting Planner của tôi làm ví dụ thực tế. Ở mỗi giai đoạn, tôi sẽ phát hành code của Meeting Planner dưới dạng các ví dụ mã nguồn mở để bạn có thể theo dõi. Tôi cũng sẽ chỉ ra các vấn đề kinh doanh liên quan đến startup khi chúng phát sinh.

Thay đổi kế hoạch cuộc họp của bạn

Khi giai đoạn thử nghiệm alpha của Meeting Planner bắt đầu, tính năng bị thiếu hụt rõ ràng nhất là khả năng thay đổi một cuộc họp sau khi đã lên lịch. Đây không phải là một vấn đề dễ dàng. Có thể thay đổi cuộc họp mà không có sự cho phép của người tham gia không? Hay bạn nên đề nghị? Hoặc thực hiện một trong hai chọn lựa, tùy thuộc vào vai trò của bạn trong việc tổ chức cuộc họp? Sẽ ra sao nếu bạn chỉ muốn hỏi liệu có ổn không khi sẽ gặp nhau sau 15 phút - việc này nên dễ dàng, đúng không?

Giải quyết tất cả điều này đòi hỏi một số suy nghĩ về các khía cạnh xã hội của việc điều chỉnh một cuộc họp.

Tôi dần nhận ra rằng khả năng điều chỉnh cuộc họp dễ dàng sau khi chúng được lên kế hoạch có thể thực hiện hoặc phá vỡ thương hiệu của Meeting Planner.

Trong phần cuối của về Advanced Scheduling (lập kế hoạch nâng cao), tôi đã triển khai thực hiện thay đổi, cho phép người tổ chức hoặc người tham gia sở hữu quyền tổ chức có thể sắp xếp lại cuộc họp mà không cần xin phép. Trong bài hôm nay, tôi sẽ hướng dẫn bạn cách xây dựng cơ sở của những yêu cầu thay đổi. Việc này cần những người tham gia yêu cầu thay đổi và sau đó những người khác có thể chấp nhận hoặc từ chối yêu cầu này, sẽ ảnh hưởng đến các thông tin của lịch họp cuối cùng.

Khi bạn đang đọc bài này, tôi hy vọng bạn sẽ thử tính năng mới "yêu cầu thay đổi" trên trang trực tuyến và chia sẻ cảm nghĩ và phản hồi trong phần bình luận bên dưới. Tôi luôn góp mặt trong các cuộc thảo luận, nhưng bạn cũng có thể liên hệ với tôi @reifman trên Twitter. Tôi luôn cởi mở với các ý tưởng về tính năng mới cho Meeting Planner cũng như các đề xuất cho các bài viết trong tương lai.

Xin nhắc lại, tất cả code cho Meeting Planner được cung cấp ở dạng mã nguồn mở và được xây dựng bằng framework Yii2 của PHP. Nếu bạn muốn tìm hiểu thêm về Yii2, hãy xem loạt bài Programming With Yii2 được đăng song song với loạt bài này.

Hãy bắt đầu nào.

Xây dựng các yêu cầu thay đổi

Một quãng đường khó khăn cần vượt qua

Bên cạnh các tính năng xem và lên lịch cuộc họp, "yêu cầu thay đổi" cần tốn thời gian và code mới nhiều hơn bất kỳ tính năng nào trong dự án này.

Như tôi đã đề cập trong phần trước, code mọi thứ với mức độ bảo mật cơ bản mất nhiều thời gian hơn tạo mẫu nhanh, nhưng việc thiết kế và xây dựng tính năng này cũng đã chạm vào rất nhiều nền tảng khác:

  • Thiết kế với kỹ thuật xã hội của yêu cầu và thay đổi lịch biểu.
  • Luôn duy trì UX cho những yêu cầu thay đổi đơn giản, giúp mọi người yêu cầu và phản hồi các yêu cầu thay đổi mà không làm lộn xộn giao diện.
  • Xử lý các yêu cầu cho các cuộc họp 1:1 sẽ dễ dàng, nhưng việc code cho tính năng nhiều người tham gia sắp tới sẽ yêu cầu cơ sở hạ tầng phức tạp hơn nhiều.
  • Xử lý các câu trả lời cho các yêu cầu với nhiều người tham gia.
  • Gửi email thông báo về các yêu cầu mới và yêu cầu đã thu hồi, các phản hồi chấp thuận hoặc từ chối.
  • Việc cập nhật xác nhận tham gia họp và chi tiết lịch khi yêu cầu được chấp thuận có ảnh hưởng đến lịch biểu.

Vì vậy, khi đây không phải là một bức tranh hoàn hảo về những thay đổi chỉ dành cho tính năng này, dưới đây là ảnh chụp màn hình của code sau cùng được lấy về từ máy chủ production.

Dưới đây là các thay đổi với code hiện thời:

Build Your Startup Request Scheduling Changes - Git Pull File Changes

Và đây là các file mới:

Build Your Startup Request Scheduling Changes - Git Pull New Files

Có rất nhiều code mới liên quan đến tính năng này.

Tables và migration

Sau cùng, tôi quyết định dùng một kiến ​​trúc được xây dựng dựa trên hai table (bảng dữ liệu). Đầu tiên là Requests:

Dưới đây là các hằng số giải thích thêm về model:

Sẽ có hai cách để điều chỉnh thời gian: TIME_ADJUST_ABIT, tức là chu kỳ (tính theo phút hoặc giờ) sớm hơn hoặc trễ hơn thời gian đã chọn, hoặc TIME_ADJUST_OTHER, một thời gian họp khác hoàn toàn.

Và table thứ hai là RequestResponses:

Về cơ bản, ai đã yêu cầu thay đổi, người trả lời yêu cầu đó và phản hồi là gì: chấp thuận hoặc từ chối.

Table thứ hai cần thiết cho tình huống có nhiều người tham gia.

Yêu cầu một thay đổi

Người tổ chức cuộc họp và người tham gia có thể truy xuất Request Changes (yêu cầu thay đổi) thông qua trình đơn Options mà chúng tôi đã tạo trong bài viết mới đây:

Build Your Startup Request Scheduling Changes - Options Menu Request Changes

Biểu mẫu yêu cầu thay đổi

Phương thức RequestCreate() của RequestController.php tải về biểu mẫu mà yêu cầu của người dùng thay đổi:

Build Your Startup Request Scheduling Changes - Request a Change Form

Và là lúc bắt đầu phức tạp Những loại thay đổi nào mà người tham gia có thể yêu cầu?

  • Bạn có muốn gặp sớm hơn hay muộn hơn?
  • Bạn có muốn gặp nhau vào một thời gian khác không?
  • Bạn có muốn gặp nhau ở một địa điểm khác không?

Chú ý: Tôi chưa triển khai khả năng thêm địa điểm và thời gian mới — hiện tại, bạn có thể chọn thời gian và địa điểm thay thế từ bất kỳ chọn lựa nào được cung cấp trong quá trình lập kế hoạch.

Một trình đơn xổ xuống của thời điểm trước và sau

Code để tạo danh sách dropdown. Tôi đã thực hiện nó để bạn có thể chọn thời gian sớm hoặc muộn hơn hai tiếng rưỡi, với khoảng tăng 15 phút gần thời gian ban đầu và tăng thêm 30 phút sau đó:

Tôi đã nhập vào $altTimesList với các khóa của từng thời điểm phù hợp với các giá trị của thời gian được điều chỉnh theo múi giờ của người dùng. Sau đó, tôi đã sử dụng ksort() để sắp xếp menu dropdown vì vậy thời gian sẽ xuất hiện theo thứ tự tăng dần.

Một trong những cố vấn của Meeting Planner (hiện tại tôi chỉ có một người) đã đề nghị hiển thị thời gian họp đang được chọn, và tôi thực hiện như dưới đây. Tôi cũng đã thêm một dấu phân tách với tùy chọn đã tắt trong trình đơn dropdown. Nó phân chia thời gian sớm ra khỏi từ những thời gian muộn hơn nhưng không cho phép chọn:

Build Your Startup Request Scheduling Changes - Enhanced Request Form with Separator

Dưới đây là code cho dropdown, code này cho thấy cách vô hiệu hóa dấu phân cách dựa trên khóa chỉ mục $currentStart:

Và, khi người tham gia muốn chọn một trong những thời điểm khác, dùng JQuery để thay đổi danh sách dropdown, thêm một việc phức tạp khi xây dựng các biểu mẫu:

Đây là /frontend/web/js/request.js:

Dưới đây là diện mạo của biểu mẫu với thời gian thay thế đã ẩn đi:

Build Your Startup Request Scheduling Changes - Selecting a different place

Các địa điểm khác nhau chỉ được tích hợp vào danh sách của địa điểm (như bạn có thể thấy với hình ảnh nổi bật nằm trên cùng).

Xử lý yêu cầu

Khi yêu cầu được đưa ra, chúng tôi sẽ thông báo cho người yêu cầu rằng những người tham gia cuộc họp khác sẽ được thông báo. Và, bất cứ khi nào có các yêu cầu cho một cuộc họp, sẽ có một liên kết đến View Them (xem các yêu cầu đó):

Build Your Startup Request Scheduling Changes - Meeting page View Requests

Tôi quyết định đây sẽ là một cách tiếp cận đơn giản, gọn gàng để mọi người truy xuất các yêu cầu.

Danh sách các yêu cầu trong cuộc họp

Dưới đây là danh sách các yêu cầu cho một cuộc họp, thường thì chỉ có một:

Build Your Startup Request Scheduling Changes - List of Meeting Requests

Request::buildSubject() tạo ra chuỗi phía trên dựa trên nội dung của yêu cầu, tức là thay đổi về thời gian và (hoặc) địa điểm:

Hàm này được sử dụng nhiều lần trong thông báo email.

Cũng có các hạn chế trong RequestController.php để tránh người dùng thực hiện nhiều yêu cầu cho mỗi cuộc họp cùng một thời điểm:

Đây là trang yêu cầu hiện thị giới hạn:

Build Your Startup Request Scheduling Changes - Viewing a Request

Nếu đó là yêu cầu của bạn, bạn có thể Withdraw Your Request (thu hồi yêu cầu lại).

Như bạn có thể thấy, có rất nhiều chức năng UX đa dạng để xây dựng điều này. Và tôi đã không cho bạn xem khi nào những người khác (không phải người yêu cầu) phản hồi lại.

Email thông báo các yêu cầu và phản hồi

Trong quá trình xây dựng các tính năng này, tôi quyết định tạo các mẫu email generic_htmlgeneric_text và hàm Request::notify() có thể sử dụng lại để giảm bớt việc phân phối các loại thông báo khác nhau cho Meeting Planner.

Đây là phương thức Request::create() để soạn email:

Mảng $content chuyển tải thành chủ đề email, tiêu đề và các đoạn văn, trong khi mảng $button được sử dụng cho bất kỳ nút bấm nào như Respond to Request hoặc View Meeting.

Đây là phương thức notify(), tương tự như các hành động send()finalize() trước đó dùng gửi email:

Về cơ bản, bố cục generic_html.php dựa trên mẫu cập nhật văn bản đơn giản mà tôi đã nói đến trong các hướng dẫn mẫu email của chúng tôi. Bố cục này cung cấp một định dạng tốt để cập nhật người tham gia qua email với một vài đoạn văn.

Đây là file của view generic_html.php tích hợp dữ liệu $content$button. Nó kiểm tra đoạn văn thứ hai và thứ ba, ví dụ: dữ liệu $p2, $p3$button:

Dưới đây là ví dụ về thông báo mà Rob Smith đã yêu cầu tôi thay đổi thời gian và địa điểm họp của chúng tôi (được tạo từ code phía trên):

Build Your Startup Request Scheduling Changes - Email Notification of Requested Change

Phản hồi các yêu cầu

Khi tôi nhấp vào Respond to Request, tôi được đưa đến phương thức actionCreate() của controller RequestResponse:

Build Your Startup Request Scheduling Changes - Respond to Request Form - Accept or Decline

Xuyên suốt UX của yêu cầu, tôi kết hợp khả năng cho mọi người viết ghi chú cung cấp ngữ cảnh cho các yêu cầu và phản hồi.

Một thách thức trong biểu mẫu này là xác định làm sao để trực tiếp phản hồi các phương thức khác nhau của controller dựa trên nút submit được nhấp vào. Nói cách khác, là sự phân biệt giữa các lần bấm nút submit theo kiểu POST.

Đây là /frontend/views/request-response/_form.php:

Về cơ bản, tôi chỉ thêm giá trị name của 'accept' hoặc 'reject' cho mỗi nút bấm. Sau đó, giá trị này được chuyển tải dưới dạng giá trị như được hiển thị:

Khi người trả lời chấp nhận hoặc từ chối yêu cầu, họ sẽ nhận được một email và nhìn thấy một thông báo ngắn gọn. Đồng thời cuộc họp không hiển thị thêm bất kỳ yêu cầu nào nữa:

Build Your Startup Request Scheduling Changes - Meeting page after Request accepted

Đây là email thông báo yêu cầu thay đổi đã được chấp thuận:

Build Your Startup Request Scheduling Changes - Email notification of requested change being accepted

Nhiều điều diễn ra trong Request::accept() bên dưới:

Trước khi gửi email, lịch họp được cập nhật để phản ánh ngày/giờ và (hoặc) địa điểm mới bất kỳ. Sau khi gửi email, cuộc họp được thông qua. Việc này cập nhật cuộc họp với file lịch họp mới đến tất cả người tham gia.

Build Your Startup Request Scheduling Changes - Updating Meeting Notice

Tiếp theo là gì?

Tôi hy vọng bạn thích bài hướng dẫn này. Việc xây dựng tính năng này mất nhiều thời gian hơn tôi dự định nhưng thật ra lại khá tốt. Tôi nghĩ rằng nó bổ sung thêm một hướng để lập kế hoạch với Meeting Planner chưa từng có so với các dịch vụ khác.

Nếu bạn chưa thử, hãy lên lịch cuộc họp đầu tiên của bạn với Meeting Planner. Tôi đã tiếp tục thực hiện những tiến triển đáng kinh ngạc đối với bản phát hành beta, mặc dù có bị phân tâm (viết code thật khó):

Tôi cũng đang lên kế hoạch viết một hướng dẫn về huy động vốn từ cộng đồng, vì vậy hãy cân nhắc theo dõi trang WeFunder Meeting Planner của chúng tôi.

Hãy chia sẻ cảm nhận của bạn dưới đây. Tôi luôn cởi mở với ý tưởng về tính năng mới và đề xuất các chủ đề cho các hướng dẫn trong tương lai. Bạn cũng có thể liên hệ với tôi @reifman.

Hãy đón chờ tất cả các hướng dẫn này và các hướng dẫn sắp tới khác bằng cách xem loạt Building Your Startup With PHP series. Và nhớ xem qua loạt bài Programming With Yii2 Series (Envato Tuts+).

Liên kết liên quan

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.